Problem with DMA from FLASH on STM32WBA52

[jeroen]

Hi all,

I am experiencing a problem with the DMA of the STM32WBA52 (on the NUCLEO-WBA52CG board) when using it to transfer data from FLASH to USART1 TX : part of the transmitted data is modified, i.e. not the data that is found in FLASH)
The problem only persists when the source is data in FLASH. When just changing the CSAR register to an address in RAM, everything works as expected (see the attached "DMA problem.txt").
When the instruction cache is activated (either 1-way or 2-way), the result is even worse.

Looking in the STM32WBA52 errata sheet, a similar problem is mentioned for FLASH to SRAM transferred (section 2.2.8). I'm not sure whether the problem mentioned there is the same.

Can somebody have a look at this and confirm that this is an error in the STM32WBA52 ?

Attached, you can find the cube MX config file (.ioc extension) and the main.c which contains the code I added. With main.c, the problem can be reproduced when line 144 is un-commented.

Best regards,

Jeroen

[_Joe_]

Hi, jeroen !

After watching your project, it looks like you are using PCLK. The problem arises from the fact that the UART is mapped to PCLK, which, in turn, depends on the system clock.

The SCM module manages the switch between HSE16 and HSE32 for the system clock, causing PCLK1 and PCLK2 clocks to switch between 16MHz and 32MHz.

This is why some receptions, especially during radio events, can be corrupted.

Solution: Using the HSI16 clock for the USART should resolve your issue.

I'm waiting for your return to find out if that resolved your issue ;)
BR, Joé.

[jeroen]

Hello Joe,

In the example code, there is nothing else that is running (no radio is configured). So no clock switching issues. Those would also be less reproducible I think.
It would also not explain why it only occurs when transferring data from Flash and not from RAM.

Besides that, ST also confirmed:

"Issue reported in the errata sheet is valid as well for DMA transfers FLASH->USART as the root cause is the cache at FLASH. "

Anyway, in the meantime we have switched to another processor (SiLabs...). Mainly for other reasons but it also "solved" the problem fur us.

Thanks for taking the time to look at it anyway !

Jeroen