STM32F765 ADC DMA problem

[Gunnar Bohlen]

Posted on May 29, 2018 at 10:01

Hello,

i'm using 7 adc-channels on  our board and use DMA to transfer all 7 results (single shot)  into my variables in DTCM memory. To initialize DMA I use sample code from similar evalboard-examples.

This works fine.

#define DTCM_MEM        __attribute__((section('dtcm_mem')))

__IO uint32_t uhADCxConvertedValue[8] DTCM_MEM;    // Important: place this variable into DTCM-Memory (0x20000000 - 0x2001FFFF)

Before I use

HAL_ADC_Start_DMA(&hEvalADC, (uint32_t*)&uhADCxConvertedValue,hEvalADC.Init.NbrOfConversion /*7*/)

I fill my result-variables with 0xFFFFFFFF.

To read new ADC-Results I check that uhADCxConvertedValue[n] is not 0xFFFFFFFF any more.

This works as well.

Now I notice something stange:

When I check for a adc-result too early (while adc conversion is not complete) the DMA seem not to copy the converted results into the memory any more. I have set breakpoints to different positions inside the adc dma driver, but it seems the DMA finishes its work without signaling an error. But results are missing.

As soon as I add a small delay osDelay(1) after HAL_ADC_Start_DMA() I get my adc-result each time. Without the delay I see 1..2 converted values.

I don't see any version number in the file

stm32f7xx_hal_adc.c,

but in uVision, Manage Run-Time Environment, version of STM32Cube HAL, ADC is V1.2.5

Does anyone have an idea what else I could check?

Is it possible that the CPU-read-access to a memory-location that the DMA wants to write to can corrupt this DMA-access?

Thank you.

[T J]

Posted on May 29, 2018 at 10:48

At full speed, there are issues in the F0 processors.

So my advice is to slow down your ADC conversion time a step or two, and slow down the ADC clock a step or two.

See if that makes a difference, then speed back up as much as you want.

I use the DMA ADC function.

I dont use the single shot, but let it run continuously, only call the setup once.

Set the DMA end of conversion interrupt, in that interrupt, copy all of your data out, but no printing inside the interrupt.

[Gunnar Bohlen]

Posted on May 29, 2018 at 11:26

Hell T J,

thanks for your thoughts.

I already used the end if conversion IRQ

HAL_ADC_ConvCpltCallback() to set a flag.

Now I copy in this callback the adc-results into my local variables which my application can access at any time and I don't see any problems any more.

Seems problem is solved 🙂

But I still would like to understand my initial problem:

Does a cpu-access to a memory-location disturb a dma-write access to the same memory-location?

Where would I see that the dma-transfer was corrupted? (I didn't see a dma error handler call)

Any comments from ST?

Thank you.

[T J]

Posted on May 29, 2018 at 11:34

Hell you too Gunnar .... hehe