Problem with LWIP generated with Cube_H7_V1.9.1

[yuri CH]

Hi!

The following was tested with Nucleo-H7ZI.

I have generated a project with basic defenition of freeRTOS and LWIP.

Once an ehternet cable is connected to the board the program collapses and goes to hardfault.

after comparing the LWIP code from current cube version to previous cube generation version that worked and still work i found that is one main difference: location of the ethernet receive buffers (ethernetif.c file, line number 87), in the problematic new version its set to 0x300400c0, in the version that works the value is 0x30040200.

Changing the value allows the code to run properly upon cable connection, moreover, i can ping the board and all seems to work well.

since this value is generated by cube i want to understand if Is this a known bug?

perhaps i am missing something?

thanks in advance.

[Pavel A.]

Yes this looks like RX buffers should be aligned on 512 bytes.

In this thread I've asked @Imen DAHMEN​ to forward this to the appropriate team to check with other ETH issues.

[Muhammed Güler]

I had a project running on STM32H723 with Rx buffer address 0x300000F0. I did some experimenting until I got to the F0 address. I have no idea what's going on in the 48 bytes in between

[yuri CH]

i have taken the 0x30040200 value because it worked in previous versions (and obviously was the cube generated value),

as i said before, this fixed the issue, but since this is part of CubeMx generated code i cant just leave it at that cause ill have a problem every time i regenerate my project.

[Adam BERLINGER]

Hello,

I think this could be misalignment between MPU settings and Ethernet buffers and descriptors.

The MPU sets first 256 bytes starting at 0x30040000 as "Device" type. The first 192 bytes are used by Ethernet DMA descriptors and rest by DMA RX buffers (exceeding the 256 bytes configured by MPU). While the "Device" is necessary for DMA descriptors, it prevents unaligned access to the memory, which is used by LwIP stack. So there are two solutions how to handle this:

1. Reconfigure the MPU region to affect only the first 192 bytes. This can be done via subregion disable option using value 0xC0 (last 2 subregions disabled) and keeping the region size to 256 bytes.
2. Move the RX buffers after the 256 bytes threshold, so it is not affected by the MPU. This can be done in ethernetif.c file in by changing the address of Rx_Buff to 0x30040100, depending on the IDE. Or in CubeMX in ETH parameters.

In general the MPU should configured in following way:

• Region 0 - General configuration, disable external memory speculative access. We recommend this to avoid some issues, and if external memories are used, overwrite this in higher regions. More info can be found here: https://www.st.com/content/st_com/en/support/learning/stm32-education/stm32-moocs/STM32_MPU_tips.html
• Region 1 - Configures non-cacheable memory for both TX and RX buffers.
• Region 2 - Configures device memory for TX and RX DMA descriptors. This has same start address as Region 1, but region with higher number overwrites the previous, so first 256 or 192 bytes are covered by this region settings.

I hope this helps.

Best regards,

Adam Berlinger

[MWB_CHa]

Hello,

I think @Adam BERLINGER​  already provided the answer but just to confirm and complement:

RX buffers address must be aligned to MPU configuration. In fact the RX buffers should not be put inside ETH DMA descriptor MPU region (Device not cacheable) but after this region.

In the Cube MX configuration, the Rx buffer is put at address 0x300400c0 and the MPU is configured as ETH DMA descriptor MPU region (Device not cacheable) form 0x30000000 to 0x300000FF so the Rx buffers are inside ETH DMA descriptor region.

Note that in the new ETH driver the RX buffers are allocated dynamically and are not set to fixed address.

Kind Regards,