on - edited on by
Laurids_PETERSE
The problem is related to two things: memory layout on STM32H7 and internal data cache (D-Cache) of the Cortex-M7 core.
In summary these can be the possible issues:
- Memory placed in DTCM RAM for D1/D2 peripherals. Unfortunately this memory is used as default in some projects including examples.
- Memory not placed in D3 SRAM4 for D3 peripherals.
- D-Cache enabled for DMA buffers, different content in cache and in SRAM memory.
- Starting the DMA just after writing the data to TX buffer, without placing __DSB() instruction between.
For Ethernet related problems, please see separate FAQ: FAQ: Ethernet not working on STM32H7x3
1. Explanation: Memory layout
The STM32H7 device consists of three bus matrix domains (D1, D2 and D3) as seen on the picture below. The D1 and D2 are connected through bus bridges, both can also access data in D3 domain. However there is no connection from D3 domain to D1 or D2 domain.
The DMA1 and DMA2 controllers are located in D2 domain and can access almost all memories with exception of ITCM and DTCM RAM (located at 0x20000000). This DMA is used in most cases.
BDMA controller is located in D3 domain and can access only SRAM4 and backup SRAM in the D3 domain.
MDMA controller is located in D1 domain and can access all memories, including ITCM/DTCM. This controller is mainly used for handling D1 peripherals and memory to memory transfers.
From performance point of view it is better to put DMA buffers inside D2 domain (SRAM1, SRAM2 and SRAM3), since the D2-to-D1 bridge can add additional delay.
2. Explanation: Handling DMA buffers with D-Cache enabled
The Cortex-M7 contains two internal caches, I-Cache for loading instructions and D-Cache for data. The D-Cache can affect the functionality of DMA transfers, since it will hold the new data in the internal cache and don't write them to the SRAM memory. However the DMA controller loads the data from SRAM memory and not D-Cache.
In case the DMA transfer is started just after writing the data to the tx_buffer in the code, it can happen that the tx_buffer data will be still in write-buffer inside the CPU, while the DMA is already started. Solution can be to set the tx_buffer as device type and force CPU to order the memory operations, or add __DSB() instruction before starting the DMA.
There are several ways how to keep manage DMA buffers with D-Cache:
- Disable D-Cache globally. It is the most simple solution, but not effective one, since you can loose great part of performance. Can be useful for debugging, to analyze if the problem is related to D-Cache.
- Disable D-Cache for part of the memory. This can be done by configuring the memory protection unit (MPU). The downside is that the MPU regions have certain alignment restrictions and you need to place the DMA buffers to specific parts of memory. Each toolchain (GCC, IAR, KEIL) needs to be configured in different way.
- Note that MPU regions can overlap and the higher region number has priority. Together with subregion disable bits, this can be useful to soften the alignment and size restrictions.
- Note that Device and Strongly ordered memory types not allow unaligned access to the memory.
- Configure part of memory as write-through. Can be used only for TX DMA. Similar to the previous option.
- Use cache maintenance operations. It is possible to write data stored in cache back to memory ("clean" operation) for specific address range, and also discard data stored in cache ("invalidate" operation).
- The downside is that these operations work withe cache-line size which is 32 bytes, so you can't clean or invalidate single byte from the cache. This can lead to errors when RX buffer "shares" the cache line with other data or TX buffer (please see the picture below).
- Beware that with uninitialized D-Cache, the maintenance operations "clean" or "clean and invalidate" can lead to BusFault exception. This is caused by uninitialized ECC (error correction code) after power-on reset. If you have project with a lot of maintenance operations and want to disable D-Cache temporarily, you can use SCB_InvalidateDCache function, which will clean the cache and set correct ECC, without enabling it.
Below are the possible MPU configurations. Green are configurations suitable for DMA buffers, blue is suitable only for TX-only DMA buffer and red are forbidden. Other configurations are not suitable for DMA buffers and will require cache maintenance operations:
3. Solution example 1: Simple placement of all memory to D1 domain
D-Cache must be disabled globally for this solution to work.
GCC (Atollic TrueStudio/System Workbench for STM32/Eclipse)
Replace DTCMRAM with RAM_D1 for section placement in linkerscript (.ld file extension). E.g. like this:
.data :
{
... /* Keep same */
} >RAM_D1 AT> FLASHThis should be done also for .bss and ._user_heap_stack sections.
In some linkerscripts, the initial stack is defined separately. So you either need to update it with the section, or define it inside the section like:
._user_heap_stack :
{
. = ALIGN(8);
PROVIDE ( end = . );
PROVIDE ( _end = . );
. = . + _Min_Heap_Size;
. = . + _Min_Stack_Size;
_estack = .; /* <<<< line added */
. = ALIGN(8);
} >RAM_D1And remove the original _estack definition.
IAR (in project settings):
For Keil:
4. Solution example 2: Placing buffers in separated memory part
D-Cache must be disabled via MPU for that particular memory region, where DMA buffer is placed. Please note that MPU region size must be in power of two. Also the regions start address must have same alignment as size. E.g. if the regions is 512 bytes, the start address must be aligned to 512 bytes (9 LSBs must be zero).
NOTE: IAR compiler and Keil compiler version <= 5 allow placing variables at absolute address in code using compiler specific extensions.
C code:
Define placement macro:
#if defined( __ICCARM__ )
#define DMA_BUFFER \
_Pragma("location=\".dma_buffer\"")
#else
#define DMA_BUFFER \
__attribute__((section(".dma_buffer")))
#endif
Specify DMA buffers in code:
DMA_BUFFER uint8_t rx_buffer[256];GCC linkerscript (*.ld file)
Place section to D2 RAM (you can also specify your own memory regions in linkerscript file):
.dma_buffer : /* Space before ':' is critical */
{
*(.dma_buffer)
} >RAM_D2This is without default value initialization. Otherwise you need to place special symbols and add your own initialization code.
IAR linker file (*.icf file)
define region D2_SRAM2_region = mem:[from 0x30020000 to 0x3003FFFF];
place in D2_SRAM2_region { section .dma_buffer};
initialize by copy { section .dma_buffer}; /* optional initialization of default values */Keil scatter file (*.sct file)
LR_IROM1 0x08000000 0x00200000 { ; load region size_region
ER_IROM1 0x08000000 0x00200000 { ; load address = execution address
*.o (RESET, +First)
*(InRoot$$Sections)
.ANY (+RO)
}
RW_IRAM2 0x24000000 0x00080000 { ; RW data
.ANY (+RW +ZI)
}
; Added new region
DMA_BUFFER 0x30040000 0x200 {
*(.dma_buffer)
}
}Generation of scatter file should be disabled in Keil:
5. Solution example 3: Use Cache maintenance functions
Transmitting data:
#define TX_LENGTH (16)
uint8_t tx_buffer[TX_LENGTH];
/* Write data */
tx_buffer[0] = 0x0;
tx_buffer[1] = 0x1;
/* Clean D-cache */
/* Make sure the address is 32-byte aligned and add 32-bytes to length, in case it overlaps cacheline */
SCB_CleanDCache_by_Addr((uint32_t*)(((uint32_t)tx_buffer) & ~(uint32_t)0x1F), TX_LENGTH+32);
/* Start DMA transfer */
HAL_UART_Transmit_DMA(&huart1, tx_buffer, TX_LENGTH);Receiving data:
#define RX_LENGTH (16)
uint8_t rx_buffer[RX_LENGTH];
/* Invalidate D-cache before reception */
/* Make sure the address is 32-byte aligned and add 32-bytes to length, in case it overlaps cacheline */
SCB_InvalidateDCache_by_Addr((uint32_t*)(((uint32_t)rx_buffer) & ~(uint32_t)0x1F), RX_LENGTH+32);
/* Start DMA transfer */HAL_UART_Receive_DMA(&huart1, rx_buffer, RX_LENGTH);/* No access to rx_buffer should be made before DMA transfer is completed */Please note that in case of reception there can be problem if rx_buffer is not aligned to the size of cache-line (32-bytes), because during the invalidate operation another data sharing the same cache-line(s) with rx_buffer can be lost.
6. References
- "AN4838: Managing memory protection unit (MPU) in STM32 MCUs"
- "AN4839: Level 1 cache on STM32F7 Series and STM32H7 Series":
- "AN4296: Overview and tips for using STM32F303/328/334/358xx CCM RAM with IAR EWARM, Keil MDK-ARM and GNU-based toolchains":
- "AN4891: STM32H7x3 system architecture and performance software expansion for STM32Cube":
Hello HTD,
So I followed the tutorial (getting started with ADC) step by step.
For reading a one time shot value from ADC it works fine:
I create the DAC and ADC:
Code:
/* USER CODE BEGIN 2 */
int value_dac=0;
HAL_DAC_Start(&hdac1, DAC_CHANNEL_2);//be sure to manually write the correct DAC channel
float voltage=0;
int value_adc=0;
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
if (value_dac < 4095-200) {
value_dac+=200;
} else {
value_dac=0;
}
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_2, DAC_ALIGN_12B_R, value_dac);
HAL_Delay(1000);
HAL_ADC_Start(&hadc1);
HAL_ADC_PollForConversion(&hadc1, HAL_MAX_DELAY);
value_adc= HAL_ADC_GetValue(&hadc1);
HAL_Delay(1000);
voltage=value_dac*0.8;
printf("DAC: %d (voltage %f) ADC: %d \r\n",value_dac,voltage,value_adc);
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
Result from printf/UART:
DAC: 200 (voltage 160.000000) ADC: 265 <\r><\n>
DAC: 400 (voltage 320.000000) ADC: 464 <\r><\n>
DAC: 600 (voltage 480.000000) ADC: 665 <\r><\n>
DAC: 800 (voltage 640.000000) ADC: 864 <\r><\n>
DAC: 1000 (voltage 800.000000) ADC: 1057 <\r><\n>
DAC: 1200 (voltage 960.000000) ADC: 1256 <\r><\n>
DAC: 1400 (voltage 1120.000000) ADC: 1459 <\r><\n>
DAC: 1600 (voltage 1280.000000) ADC: 1659 <\r><\n>
Now, I want to use a DMA to continuously read from the ADC.
As a first step I don't use a buffer but still one int for value_adc and it should get updated as the tutorial suggests.
I create the DMA and update the ADC. I don't change the DAC.
Code:
/* USER CODE BEGIN 2 */
int value_dac=0;
HAL_DAC_Start(&hdac1, DAC_CHANNEL_2);//be sure to manually write the correct DAC channel
float voltage=0;
int value_adc=0;
HAL_ADCEx_Calibration_Start(&hadc1,ADC_CALIB_OFFSET,ADC_SINGLE_ENDED);
HAL_ADC_Start_DMA(&hadc1,(uint32_t*)&value_adc,1);
/* USER CODE END 2 */
/* Infinite loop */
/* USER CODE BEGIN WHILE */
while (1)
{
if (value_dac < 4095-200) {
value_dac+=200;
} else {
value_dac=0;
}
HAL_DAC_SetValue(&hdac1, DAC_CHANNEL_2, DAC_ALIGN_12B_R, value_dac);
HAL_Delay(1000);
HAL_Delay(1000);
voltage=value_dac*0.8;
printf("DAC: %d (voltage %f) ADC: %d \r\n",value_dac,voltage,value_adc);
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
}
Result
DAC: 200 (voltage 160.000000) ADC: 0 <\r><\n>
DAC: 400 (voltage 320.000000) ADC: 0 <\r><\n>
DAC: 600 (voltage 480.000000) ADC: 0 <\r><\n>
DAC: 800 (voltage 640.000000) ADC: 0 <\r><\n>
DAC: 1000 (voltage 800.000000) ADC: 0 <\r><\n>
DAC: 1200 (voltage 960.000000) ADC: 0 <\r><\n>
So I guess the value_adc doesn't get update. I guess there is missing some kind of trigger to say that it should be updated with the DMA.
It seems like you need "Continuous conversion mode" enabled:
Then, using DMA I don't use HAL function to read value. I just start reading with HAL, then I read the data directly from my buffer.
I set the callback to be notified when the conversion is complete:
HAL_ADC_RegisterCallback(m_hadc, HAL_ADC_CONVERSION_COMPLETE_CB_ID, conversionComplete);Inside the function `conversionComplete` I just calculate the average from all samples in the buffer and trigger another notification when it's done. Of course instead of averaging the values you can do anything else with them, like copy them somewhere else.
I would paste my code but it's unnecessarily complex because it handles multiple channels and performs additional calculations, also it's done in C++. The only important part is the function takes `ADC_HandleTypeDef` as the only parameter. As this is an ISR, whatever you do in that function must be done very quickly, without blocking or god forbid waiting. So using UART from it is a no-no. It only averages the values and sets a variable that tells the other thread in my code that the new value is ready to be read. Then the other thread just reads the result. So in case of no OS used - your main thread is your main loop. It can loop and test if you set a special variable that the value is ready, when it's ready read it and send it to the UART, then clear the flag and loop. The callback mentioned earlier is responsible for actual reading exactly when the data from ADC is ready. Remember to not block / wait in callback, otherwise you would deadlock the MCU and it won't work.
Looking at your screenshot, you have `Conversion Data Management Mode` set to `Regular Conversion data stored in DR register only`, I believe it should be set to `DMA Circular Mode`.
Here's how it's set in my project:
BTW, try to use more than 1 word for the data, define a buffer for like 128 samples as array. If your resolution is set to 12 bits, that the closest word size will be 16-bits. So I would use an array of let's say 128 of `uint16_t`, the length of the data should be 128 (number of 16-bit words). That's what I believe is half word in DMA settings, here:
Also be sure to have IRQ enabled:
Then the registered callback function should start to be called. And the elements of the buffer array should contain the measured values. I guess the main point of using DMA here is to quickly get many samples without interrupting MCU. So if you set like 128 samples (buffer size) - you will get the interrupt and the callback called when all of the samples are written in the buffer, so not on the single reading, but when multiple readings complete. IDK, maybe it would just work on a single value, but I haven't tested it. Try to replace single value with a buffer (and best make it length divisible by 4), then in the callback try to calculate the average of the values in the buffer, then copy result to another variable. Then in your main loop just print this value using UART debugger function. Please tell me if it worked.
For anyone trying Solution example 2: Placing buffers in separated memory part, remember that by default RAM_D2 is not powered on.
To make this example work I had to add this to the start of main:
__HAL_RCC_D2SRAM1_CLK_ENABLE();
And because it isn't part of the normal MCU initialization, any data mapped to this section will NOT be initialized. So, for me, it was easiest to only place my receive buffer in RAM_D2.
And here is my CubeMx setup:
