STM32F769 SDMMC corruption with Ethernet DMA?

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?

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

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

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.

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