STM32F769 SDMMC corruption with Ethernet DMA?

[James Murray]

Hi,

On STM32769NI EVAL board I have LWiP running the ethernet port. This is a merge of two pieces of example code that come with the Cube.

I also have SDMMC being read by FATfs.

Prior to adding Ethernet, all was well. Now, calls to HAL_SD_ReadBlocks_DMA (called by f_read in FATfs) are sometimes returning no data, but the result code says all is OK !

Commenting the initialisation of ethernet makes it work again.

Any ideas on where to start looking? It kind of seems like something in the ethernet module is breaking the SDMMC DMA, but how? I've been looking through the code and reference manual for a number of hours now with no improvement in sight.

I find it particularly troubling that a broken transfer at the low level is returning a good error code.

James

[Tesla DeLorean]

What memory addresses are the SDMMC DMA occurring at, and doesn't it change based on dead-code elimination of Ethernet code?

Does behaviour change if both Ethernet and SDMMC are enabled and SDMMC transfers are constrained to DTCMRAM?

[James Murray]

Currently the Ethernet code is using whatever RAM the examples had it using(!)

The SDMMC is reading to general RAM that FATfs has allocated. The receive buffer isn't being stomped on though, it doesn't seem to be written at all. Almost as if something else broke the DMA transaction or re-wrote the transfer addresses.

It still breaks even if the Ethernet is only partially initialised. i.e. I call lwip_init() and Netif_Config() but don't actually allocate a tcp_pcb. I commented out the mainloop calls to the ethernet timer function and the bad behaviour is still there.

The code that is active enables that hardware, module clocks, ETH DMA etc. I haven't refined it to see precisely which enable statement triggers the problem.

The memory address being used for the FATfs buffer (SDMMC DMA read target) while debugging just now was 0x2000DDD4 which falls within the DTCM region.

James

[James Murray]

OK, some more info. This is perhaps pointing towards an incomplete merge of the two examples.

There's no non-RTOS example of LWiP for the STM32F769 Discovery that I can see. (I said eval above in error.)

With Ethernet descriptors or arrays in DTCM I get working pings but SDcard data is corrupted when read back over USB. The corruption is happening at the SDMMC DMA stage.

With Ethernet descriptors and arrays in SRAM1 or SRAM2 I don't get working pings but the SDcard data is good. Oddly and perhaps a clue, when I'm reading SDcard data back over USB, the pings work and the data is still good.

Almost like the ethernet DMA needs a "kick" to work when in SRAM1 or 2 ? A simple configuration I missed?

James

[Tesla DeLorean]

Have a STM32F779I-EVAL (crypto version of 769I), don't have a good framework to test SDMMC interaction with other functionality.

Should probably try and work-up an SDMMC/USB-MSC test.

[James Murray]

OK, now fixed.

Main changes:

my linker file didn't have the sections defined that the C-code was expecting.

Having moved them into SRAM2, I then had to adjust the position of the stack to avoid a collision.

I didn't have the correct MPU settings. The areas used by ethernet need to be non-bufferable and non-cacheable.

Now it seems to be working as expected with no collisions with USB, SDMMC, SPI or I2C.

James