It is strongly recommended to follow the same configuration as in examples provided in STM32CubeH7 package:
The following conditions should be met:
- TX and RX DMA descriptors (defined in ethernetif.c file) should be located in D2 SRAM and be configured by MPU as Device memory or Strongly-ordered type.
- These should be set by default by CubeMX for IAR and Keil IDEs. For GCC, you need to modify the linkerscript (please see the examples)
- MPU configuration can be found in main.c file in the example
- RX buffer (defined in ethernetif.c file) should be located in D2 SRAM and must not be configured as Device memory type (because IP stacks like LwIP can access the received data unaligned).
- This is also set by default by CubeMX for Keil and IAR IDEs. Again For GCC, you need to modify the linkerscript (please see the examples)
- Shouldn't be placed in MPU region of TX and RX DMA descriptors
This is how it is implemented in STM32CubeH7 examples, and it works with the current implementation of the library (v1.2.0). Other configurations (e.g. MPU) might also work, but might also fail with specific compiler options (especially with optimization flags).
The data are managed by the dedicated DMA in the Ethernet peripheral. This means that:
- Receive and transmit buffers must be accessible by DMA
- All data (including DMA descriptors) must be effectively written to the SRAM before triggering/enabling the DMA
The Cortex-M7 can perform accesses to Normal memory type out-of-order. So if we have sequence write to SRAM (Normal type by default), then write to Ethernet register (Device by default), those two operations can be switched by the CPU. And this actually happens in some cases.
So the TX and RX DMA descriptors should be configured to Device or Strongly-ordered type, since:
- accesses to Device type must be performed in-order compared to other Device type accesses
- accesses to Strongly-ordered type must be executed in-order to all other types (Strongly-ordered access acts as memory barrier).