cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H743 Ethernet: can ETH access SRAM4?

LDroz.2
Associate II

Hello, I am writing a driver for the Ethernet interface, and I noticed it fails to read data from buffers lying in SRAM4 (0x38000000 - 0x3800FFFF), with a Fatal Bus Error. According to the MCU's Reference Manual (RM0433) 2.1 Table 3, and 2.1.6 Ethernet MAC, it should be able to access it.

What else could cause such an access to fail?

Here are my observations / remarks:

  • It works using buffers lying in SRAM1-3, which has the exact same MPU configuration, minus the size of course. The configuration of the memory region spanning SRAM4 is:
    • Executable, read-write, normal, non-shareable, cacheable, non-bufferable,
    • Start = 0x38000000, length = 64 KiB
  • I am aware keeping the memory type to normal and cacheable requires invalidating / flushing cache lines when needed, as well as ensuring relative execution order of writes to descriptors & buffers vs. updating the tail pointer, which I do.
  • I checked the programmed length of the buffer in the descriptor, and it is not too long so as to cause the ETH DMA to read beyong the upper limit of SRAM4.
  • Why are these buffers in SRAM4 while the reference manual recommends placing them in SRAM3?
    • I am using the LwIP library, which allocates some buffers as global arrays (PBUF_POOL type), for reception. In some cases due to how the library is written, buffers allocated for reception may be reused for transmission. With my OS configuration, all global data (arrays, initialized or not) are placed in SRAM4. Changing this would require chaning the linker configuration, which I would ideally avoid.
  • SRAM4 is in domain D3 while the ETH and SRAM1-3 are in domain D2. There is a bridge linking both domains. Does it require any configuration? The reference manual does not mention anything, so I assume it doesn't.
  • Could this be related to the configuration of bus accesses by the ETH DMA to the AHB bus matrix? Perhaps contention issues to SRAM4 since all other program data lies there too?

Apologies if I am missing something obvious.

Best regards.

2 REPLIES 2
Pavel A.
Evangelist III

> and I noticed it fails to read data from buffers lying in SRAM4 (0x38000000 - 0x3800FFFF),

Noticed where? Most examples use the SRAM at 0x30040000.

In my own driver implementation, which, combined with LwIP, my OS (a proprietary design from my company) and its linker script, places packet buffer payloads in SRAM4 by default.