AnsweredAssumed Answered

STM32F765 ADC DMA problem

Question asked by Gunnar Bohlen on May 29, 2018
Latest reply on May 29, 2018 by T J

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.

Outcomes