Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

mec15xxevb_assy6853: tests/drivers/adc/adc_api asynchronous test failed #49601

Closed
hunterhu3000 opened this issue Aug 27, 2022 · 1 comment
Closed
Assignees
Labels
bug The issue is a bug, or the PR is fixing a bug platform: Microchip MEC Microchip MEC Platform priority: low Low impact/importance bug

Comments

@hunterhu3000
Copy link
Collaborator

hunterhu3000 commented Aug 27, 2022

Describe the bug
mec15xxevb_assy6853 board daily test tests/drivers/adc/adc_api asynchronous test failed

Please also mention any information which could help others to understand
the problem you're facing:

  • What target platform are you using? mec15xxevb_assy6853
  • What have you tried to diagnose or workaround this issue? Found a WA.
  • Is this a regression? No, this problem is randomly happen.

To Reproduce
Steps to reproduce the behavior:

  1. west build -p always -b mec15xxevb_assy6853 tests/drivers/adc/adc_api/

Expected behavior
The test can pass

Impact
1 test case fail in daily test.
Some times the ADC will lost a sample.

Logs and console output
Original log

*** Booting Zephyr OS build zephyr-v3.1.0-4237-g6c03cb9fb433  ***
Running TESTSUITE adc_basic
===================================================================
START - test_adc_asynchronous_call
Samples read: 0x0af3 0x0af4 0x0af3 0x0af4 0xffff8000
    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/adc/adc_api/src/test_adc.c:447: check_samples: (INVALID_ADC_VALUE equal to sample_value)
[4] should be filled
 FAIL - test_adc_asynchronous_call in 0.021 seconds

Add some printk

            568:@@@ test_task_asynchronous_call
            570:adc_xec_read_async
            573:@@@ adc_read_async done
            575:xec_adc_get_sample:v channels = 16, bit = 5
            578:xec_adc_get_sample: *data->buffer = 2803
            582:adc_context_on_sampling_done
            584:@@@ ctx->sampling_index = 0
            587:@@@ adc_context_start_sampling
            589:z_impl_k_poll
            591:xec_adc_get_sample:v channels = 16, bit = 5
            595:xec_adc_get_sample: *data->buffer = 2803
            598:adc_context_on_sampling_done
            600:@@@ ctx->sampling_index = 1
            603:@@@ adc_context_start_sampling
            605:poll: z_pend_curr before
            608:xec_adc_get_sample:v channels = 16, bit = 5
            612:xec_adc_get_sample: *data->buffer = 2803
            615:adc_context_on_sampling_done
            617:@@@ ctx->sampling_index = 2
            620:@@@ adc_context_start_sampling
            624:xec_adc_get_sample:v channels = 16, bit = 5
            627:xec_adc_get_sample: *data->buffer = 2803
            631:adc_context_on_sampling_done
            633:@@@ ctx->sampling_index = 3
            636:@@@ adc_context_start_sampling
            646:xec_adc_get_sample:v channels = 0, bit = 0     //channels should be 16 here.
            650:adc_context_on_sampling_done
            652:@@@ ctx->sampling_index = 4
            655:@@@ finish = true
            656:@@@ k_poll_signal_raise
            659:z_impl_k_poll_signal_raise
            662:poll: z_pend_curr after
            664:@@@ k_poll done
            666:check_samples: 2803 2803 2803 2803 -32768
           6629:

Environment (please complete the following information):

  • OS: (e.g. Linux, MacOS, Windows): Ubuntu 20.04
  • Toolchain (e.g Zephyr SDK, ...) 0.15.0
  • Commit SHA or Version used: 6c03cb9

Additional context
The test will collect 5 samples of the ADC.
In the last sample, the interrupt is triggered, but the register shows there is no channel that have the ADC data.
If there is there is no ADC channel ready, there should not be an interrupt.
But in this case, I think the interrupt is correct, the problem is the adc_regs->status_reg not correct. If manually set the channel of last sample to 16, the case can pass correctly. So we need to analyze why this value is 0.

the WA

  1. In the test test_task_asynchronous_call(), change k_poll(&async_evt, 1, K_MSEC(1000)) to k_poll(&async_evt, 1, K_MSEC(500)), this problem will not happen.
    If change the timer to 2000ms, the problem will 100% happen.
  2. if the adc_regs->status_reg is 0, set the the value of it to the value of the last sample.
@hunterhu3000 hunterhu3000 added the bug The issue is a bug, or the PR is fixing a bug label Aug 27, 2022
@mengxianglinx mengxianglinx added the platform: Microchip MEC Microchip MEC Platform label Aug 29, 2022
@mmahadevan108 mmahadevan108 added the priority: low Low impact/importance bug label Aug 30, 2022
@hunterhu3000
Copy link
Collaborator Author

Close as the bug is unable to reproduce for some days

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug The issue is a bug, or the PR is fixing a bug platform: Microchip MEC Microchip MEC Platform priority: low Low impact/importance bug
Projects
None yet
Development

No branches or pull requests

4 participants