STM32H7's I2C4 using BDMA not triggering Complete Callbacks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-29 7:18 AM
I'm using an STM32H725 to communicate with an i2c sensor. I'm using the I2C4 bus with the HAL DMA functions. I also enabled the BDMA channels for the rx and tx and respective interrupts. The problem is that the complete rx/tx callbacks are not triggered.
I found that this could be related to the problem described here: https://st.my.site.com/community/s/article/FAQ-DMA-is-not-working-on-STM32H7-devices
Any solutions to this problem?
- Labels:
-
DMA
-
I2C
-
STM32H7 series
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-30 8:19 AM
I use STM32CubeIDE I think it uses GCC compiler
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-30 9:23 AM - edited ‎2023-11-20 4:25 AM
Open the linker script file STM32H725RGVX_FLASH.ld :
- Make sure that the memory region definition for SRAM4 (RAM_D3) exist.
Then In your source code, Define a custom section: Start by defining a custom section using the __attribute__((section("section_name"))) attribute. For example :
uint8_t __attribute__((section(".RAM_D3"))) Tx_I2C[1];
Foued
To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2023-05-31 1:04 AM
I checked both in the FLASH.ld and RAM.ld files and the RAM_D3 exists in both. I retested
uint8_t __attribute__((section(".RAM_D3"))) Tx_I2C[1];
And still not working.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
‎2025-04-09 1:31 PM - edited ‎2025-04-28 7:09 AM
The easiest way may be to manage the memory yourself, e.g.:
uint8_t* ramd3 = 0x38000000;
now, as long as the linker doesn't put anything there, you can manage those 64K of ramd3 for yourself (I got the offset and size from the .ld file, so double check it there for your platform). To prevent the linker from placing stuff in there inadvertently, you could remove the RAM_D3 entry from the .ld file.
If instead you want to do it the proper way, using `__attribute((section.(..)))__` , you need to add a SECTION (hence the name) to the .ld file, e.g.: inside the existing SECTIONS block, add:
.ramd3 :
{
KEEP(*(.RAM_D3_SECTION))
} >RAM_D3
Then you can declare your variables as
uint8_t __attribute__((section(".RAM_D3_SECTION"))) Tx_I2C[1];
Should the HAL report this error in a better way? I think so https://github.com/STMicroelectronics/STM32CubeH7/issues/315
Note that if you use objcopy to create binaries you need to explicitly exclude this section or you'll get an 800 MB binary:
arm-none-eabi-objcopy -O binary -R .ramd3 FILE.elf FILE.bin

- « Previous
-
- 1
- 2
- Next »