ADC DMA fails on FRDM K64F

[teburd]

Describe the bug
The adc_dma test, buildable using

west build -p always -b frdm_k64f -T tests/drivers/adc/adc_dma/drivers.adc-dma

fails since commit
6e21ebf

It looks like perhaps the NXP specific changes made in this commit broke things.

Test output if helpful

*** Booting Zephyr OS build zephyr-v3.3.0-1492-ga57810dc3b1e ***
Running TESTSUITE adc_dma
===================================================================
START - test_adc_asynchronous_call

    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/adc/adc_dma/src/test_adc.c:308: test_task_asynchronous_call: (ret not equal to 0)
k_poll failed with error -11
 FAIL - test_adc_asynchronous_call in 1.015 seconds

[teburd]

@heinwessels please take a look, commit points to a change you made to the test

[heinwessels]

The failure shown in the description is caused by me changing the interval_us from HW_TRIGGER_INTERVAL to 0. I know this is fine the STM32 so I incorrectly assumed it should work for the NXP as well. I asked teburd to see if that fixes it, and it's definitely a problem. However, the test fails at a new location afterwards.

*** Booting Zephyr OS build zephyr-v3.3.0-1492-ga57810dc3b1e ***
Running TESTSUITE adc_dma
===================================================================
START - test_adc_asynchronous_call
Samples read: 0x0372 0x0000 0x00f4 0x0000 0x037a 0x0000 
    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/adc/adc_dma/src/test_adc.c:176: check_samples: (INVALID_ADC_VALUE not equal to sample_value)
[5] should be empty
 FAIL - test_adc_asynchronous_call in 0.021 seconds
===================================================================
START - test_adc_invalid_request
E: Invalid resolution
E: Invalid resolution
Samples read: 0x0034 0x0000 
    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/adc/adc_dma/src/test_adc.c:176: check_samples: (INVALID_ADC_VALUE not equal to sample_value)
[1] should be empty
 FAIL - test_adc_invalid_request in 0.022 seconds
===================================================================
START - test_adc_repeated_samplings
repeated_samplings_callback: done 1
Samples read: 0x0201 0x0000 
    Assertion failed at WEST_TOPDIR/zephyr/tests/drivers/adc/adc_dma/src/test_adc.c:176: check_samples: (INVALID_ADC_VALUE not equal to sample_value)
[1] should be empty
ASSERTION FAIL [0] @ WEST_TOPDIR/zephyr/kernel/sched.c:1750
        aborting essential thread 0x200007e0
E: r0/a1:  0x00000004  r1/a2:  0x000006d6  r2/a3:  0x00000080
E: r3/a4:  0x00002de5 r12/ip:  0x00000000 r14/lr:  0x0000663f
E:  xpsr:  0x41000011
E: Faulting instruction address (r15/pc): 0x00007c20
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Fault during interrupt handling

E: Current thread: 0x200007e0 (main)
E: Halting system

It's likely the crash is called by a test failing, but the cause of the test failing concerns me. INVALID_ADC_VALUE not equal to sample_value is a check I added, copied directly from adc_api, where it verfies the buffer is filled correctly. I'm wondering if this could point to a bug in the driver?

[hakehuang]

It's likely the crash is called by a test failing, but the cause of the test failing concrens me. INVALID_ADC_VALUE not equal to sample_value is a check I added, copied directly from adc_api, where it verfies the buffer is filled correctly. I'm wondering if this could point to a bug in the driver?

Thanks @heinwessels for qiuck analysis, I am checking the driver.

[heinwessels]

Having a look at adc_mcux_adc16.c it seems like the dma_block.block_size is set bigger than it should be, which would explain the (INVALID_ADC_VALUE not equal to sample_value) error.

The potential problematic code is here:

zephyr/drivers/adc/adc_mcux_adc16.c

Line 275 in 1dce3c3

data->adc_dma_config.dma_block.block_size = ctx->sequence.buffer_size;

When starting the DMA the bytes-to-transfer (called block_size) is set to sequence->buffer_size. And for the test, the buffer_size is set to the actual size of the buffer, which is much larger than it needs to be for this specific test, in this case 24.

IMO buffer_size is the size of the buffer, and should not be used. (only to check that it's indeed big enough). Instead the block_size should be set to something like sizeof(sample).

In the STM32 driver we set it explictly to the number of channels samples multiplied by the size of each sample, and ignore the actual size of the buffer.

zephyr/drivers/adc/adc_stm32.c

Line 319 in 1dce3c3

blk_cfg->block_size = channel_count * sizeof(int16_t);

@hakehuang do you think this might be it?

[hakehuang]

@heinwessels , I will craete a PR for this fix, btw will you fix the interval_us issue, or you want to fix in as well?

[heinwessels]

@heinwessels , I will craete a PR for this fix, btw will you fix the interval_us issue, or you want to fix in as well?

I'll create a fix for this one. It doesn't seem to be blocking the CI, so I think it's fine if it's two seperate PRs.

Thanks!

[heinwessels]

@hakehuang I'm not sure how to fix the tests in a generic way, because I'm not sure of what the NXP drivers need. Could you possibly tell me why? For example, before my changes, the interval_us was set to 3 different values in three different tests.

For test_task_asynchronous_call it's set to HW_TRIGGER_INTERVAL = 2 .

zephyr/tests/drivers/adc/adc_dma/src/test_adc.c

Lines 247 to 248 in aac0328

	/* Start consecutive samplings as fast as possible. */
	.interval_us = HW_TRIGGER_INTERVAL,

For test_task_with_interval it's set to 500.

zephyr/tests/drivers/adc/adc_dma/src/test_adc.c

Line 312 in aac0328

.interval_us = 500UL, /*make this double to sample time*/

For test_task_repeated_samplings it's set to 10000.

zephyr/tests/drivers/adc/adc_dma/src/test_adc.c

Lines 401 to 403 in aac0328

	/* Start consecutive samplings as fast as possible. */
	/* but the interval shall be larger than the HW trigger*/
	.interval_us = SAMPLE_INTERVAL_US,

For me this all seems like it should all be replaced with a single value, because that's the minimum value that seems to work, and most tests can use that. So I can replace the test_task_asynchronous_call and test_task_repeated_samplings with this value.

#define MINIMUM_SAMPLING_TIME = 2

The only test that might need a different timing is test_task_with_interval, but the actual timing isn't tested at all, so technically the interval_us could be set to 2 as well. However, it seems to me that this test is a special case and needs an additional

#define INTERVAL_SAMPLING_TIME = 500

// in the test_task_with_interval test

options.interval_us = INTERVAL_SAMPLING_TIME;
zassert_true(milliseconds_spent > ( options.extra_samplings * INTERVAL_SAMPLING_TIME ), "...");

What do you think? Can I fix the tests this way?

[hakehuang]

What do you think? Can I fix the tests this way?

the sample interval depends on the hardware mode, the minial interval is 2us for nxp paltforms(consider the longsample mode), and our adc is triggerred by a counter timer form HW, the counter is set to 2us as well. As to the 500US and 1000US, it is because I want to make sure the sample interval is double of the sample interval time, such as I can get exact a new data back.

[hakehuang]

@heinwessels , I will craete a PR for this fix, btw will you fix the interval_us issue, or you want to fix in as well?

I'll create a fix for this one. It doesn't seem to be blocking the CI, so I think it's fine if it's two seperate PRs.

Thanks!

For the changes to

blk_cfg->block_size = channel_count * sizeof(int16_t); 

How can the driver know the expect result to return? in your test it is 1 plus 4 extra, but buffer given 24. and I did not see an option pass to driver on the exact number of results expected. say if someone wants 2 records in adc read, how could they do this? @heinwessels