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 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
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?