STM32H743IIx DMA from AXI SRAM to external SDRAM not writing all SDRAM addresses correctly.

[dmainz]

I wrote a test that uses the DMA2D to transfer 64kB of data from AXI SRAM to an external SDRAM.  I set the source data to be all 0xFF and started the DMA.  Using the Memory viewer in STM32CubeIDE I see that the SDRAM is getting filled, but there are random gaps filled with 0.  There is no pattern to the gap spacing.  Example gap shown here.  The zeros were written because there were F's at those addresses previously.

The MPU is enabled and set as follows:

I set AXI_TARG7_FN_MOD.READ_ISS_OVERRIDE to 1 according to STM32H742x/743xI/G, STM32H750xB and STM32H753xI device errata section 2.29.

As an experiment, I added a section of AXI SRAM to the MPU config, set it to full access and placed my source buffer at that address.  The transfer happened correctly.  There were no gaps.

What is happening here?  Note that using the MDMA gives the same results.  Also the gaps appear in different places from run to run.

[Pavel A.]

Please try to compare/checksum the data in your code instead of viewing in IDE. What you see can be artifact of the debugger (interference with DMA, caching...)

 

[dmainz]

Hi Pavel,

Thanks for responding.  Valid point.  I did see a difference between the compare fails vs. what was on the Memory viewer.  There are addresses that don't fail, but show up as 0 instead of the written value in the Memory viewer.  However there are still gaps that fail (read 0) which also show up as 0 in the Memory viewer.  I used an incrementing data pattern as TDK suggested.  A fail log snippet is shown below (the address reported is the offset into 0xD0000000, the SDRAM space).

sdram read fail: exp c, got 0 at 70c
sdram read fail: exp d, got 0 at 70d
sdram read fail: exp e, got 0 at 70e
sdram read fail: exp f, got 0 at 70f
sdram read fail: exp 10, got 0 at 710
...

When I create a section of the AXI SRAM that has ALL ACCESS in the MPU config and place the src buffer at that address, the fails go away.

I'm trying to understand why this works.

[TDK]

Slow the SDRAM clock down by a factor of 10. Still happen? If not, probably a bad layout.

Consider populating memory with more interesting/traceable data. Such as 0x0001 0x0002 0x0003, ... . Then, if it still gets mixed up, you have more of an idea where and how it happened. And if gaps occur, you can determine if bytes were dropped, skipped, inserted, or corrupted.

What is the pedigree of the board?

[dmainz]

Hi TDK,

Thanks for responding.  I tried the data pattern you suggested and I see that the data gets transferred correctly until a 0 gets written in place of the expected value.  See my answer to Pavel above for a snippet from a fail log.

I don't think it's a board layout thing because the transfers happen flawlessly when the MPU is disabled.  Even using the SDRAM as a frame buffer for an LCD works without any display issues.

Granted the board layout is not the best due to the antennas on the SDRAM pins.  It's an OpenH743I-C board with SoM from WaveShare.