cancel
Showing results for 
Search instead for 
Did you mean: 

[STM32h7] ADC3 BDMA Transfer error (Buffer located in SRAM4)

EZamo.1
Associate III

I understand the STM32H7's BDMA requires special attention to the memory map [FAQ: DMA is not working on STM32H7 devices]

however, when I try to declare the buffer to SRAM4 that will be the destination for the ADC DMA transfer,

__attribute__((at(0x38000000)))uint32_t pAdcBuffer [ 1024 ] = {0};
 
OR..
 
#define SRAM4_BDAM_BUFFER __attribute__((section("RAM_D3")))
SRAM4_BDAM_BUFFER uint32_t pAdcBuffer [ 1024 ] = {0};

it compiles, but neither works as I still get a DMA error code of 1 (transfer error) when I start:

HAL_ADC_Start_DMA (&hadc3 , (uint32_t*)pAdcBuffer, 256 );

Is there an another preferred way of declaring the variable to SRAM4 via code, and not linker-script? I don't mind using the linker-script, but not very familiar with it. But I did also try it without success:

STM32H743ZITX_RAM.ld:
  ._ramd3_aka_sram4(NOLOAD) :
  {
    . = ALIGN(4);
    *(._ramd3_aka_sram4*)
  } >RAM_D3
 
mainc.c:
__attribute__((section("_ramd3_aka_sram4"), used))
uint32_t pAdcBuffer [ 1024 ] = {0};

Otherwise, if not a memory map issue, what else could be the problem?

6 REPLIES 6
Imen GH
ST Employee

Hello,

I confirm for BDMA usage you must select the SRAM4. According to RM0433 Rev 6 (page 128), SRAM4 is mapped at these address (0x38000000 to 0x3800FFFF).

So, it is necessary to insert these addresses manually in the stm32h743xx_flash.icf file generated by CubeMX. This file contains information about the allocated memory:  

define symbol __ICFEDIT_region_RAM_start__    = 0x38000000;

define symbol __ICFEDIT_region_RAM_end__      = 0x3800FFFF;

Otherwise, you can do it as shown in the figure (attached).

Best Regards

EStua.1
Associate III

I ran into this issue but i should point out you don't need to use BDMA for ADC3 on some STM32H MCUs - you can use DMA1 stream X instead and avoid this issue all together.

Same issue on STM32H7​ with ADC3+BDMA, previously reported by @Community member​ 

ADC3+BDMA+memory buffer at 0x38000000 (RAM_D3 aka SRAM 4) - error

ADC3+DMA1+memory buffer at 0x24000000 (RAM_D1 aka AXI SRAM) - works, as @EStua.1​ pointed out

Disappointed with crowdfunding projects? Make a lasting, meaningful impact as a Tech Sponsor instead: Visit TechSponsor.io to Start Your Journey!
Georgy Moshkin
Senior II

@Community member​ , @EStua.1​ . I found BDMA + ADC3 solution. The problem is that by default STM32Cube code generator places MX_ADC3_Init() function call before BDMA is initialized:

/* Wrong order */
MX_ADC3_Init();
MX_BDMA_Init();

You may quickly test it by manually changing the order to

/* Correct order: BDMA first, and then ADC3 */
  MX_BDMA_Init();
  MX_ADC3_Init();

Because this part of code is rewritten during code generation, it is better to change it using STM32 Device configuration tool:

  1. Open "Project Manager" (tab near Pinout / Clock Configuration)
  2. Project Manager → Advanced Settings → Generated Function Calls
  3. use arrows to move MX_ADC3_Init below MX_BDMA_Init

Note that using DMA1 stream for ADC3 may be not very efficient if you already have many things running on DMA1. From my understanding BDMA and DMA1 in parallel may free up some resources for the tasks requiring highest performance, and also increase amount of RAM used simultaneously in DMA mode.

Disappointed with crowdfunding projects? Make a lasting, meaningful impact as a Tech Sponsor instead: Visit TechSponsor.io to Start Your Journey!

Totally right, changing the order of the init function calls worked for me!

Thanks!

Thank you, it worked for me, I used another stream and no problem :)

To make that at the cubeide in the ADC3 you must go to DMA, add and then change in the BDMA to a DMA and stream not used by other ADCs  ADC working-2.png