H743zi2 LwIp/ETH FW 1.7 to 1.9 now fails to respond

[MEdgerton]

I have a working H743zi2 FW 1.7 which does a ping and web respond and works great.

I moved to FW 1.9 and a new project now fails to even ping.

The interesting part is that if I run the project based on FW1.7 first, keep power on, then run the one based on FW1.9 the new project works.

If I power down then back up it then stops working.

It looks like FW1.9 is now not initiallising something properly. Its pretty clear as its completely repeatable.

I have checked the IO (as it now defaults to Slow on ETH pins) and forced it to Very High. Still not a fix.

Has anyone any ideas. Clearly something got broken from FW 1.7 to 1.9, which is frustrating.

If I can get it working then I have a working solution that from reading other posts I'm sure would be useful!

[MEdgerton]

UPDATE: I created a new project again FW1.9 and this one works.

Note: the previous one I had started adding new IO to it. The LWIP and ETH and MPU are all configured the same in the .ioc.

I have put the problem project back to the same settings but it still does not work unless a working project is run first.

The new project now breaks after enabling SDRAM in FMC.

Disabling the SDRAM again and the problem persists.

I think the change causes something to permanently break.

[Piranha]

No amount of clicking Cube or other wild dances can fix a broken code.

https://community.st.com/s/question/0D50X0000C6eNNSSQ2/bug-fixes-stm32h7-ethernet

https://community.st.com/s/question/0D50X0000BOtfhnSQB/how-to-make-ethernet-and-lwip-working-on-stm32

And yes, my topic is up to date and still relevant.

[MEdgerton]

Thank you @Piranha​ I had seen your useful links before. As above I actually have FW1.7 working and FW1.9 working when not using the FMC. This is for ping and the httpd server. It is repeatable and through testing I haven't got it to fail unless I try and use the FMC. I am now working through the steps to isolate which bit breaks it.

It didn't need too many fixes to work (both FW1.7 and 1.9 initially). I'll list them in a seperate comment.

I do note that the exact changes to the MPU seem to show two similar set of settings. One uses 2 MPU areas, one 3. They are simila. I will post again seperatl as a comment as knowing which ones are correct for proper use is needed.

I am using the Nucleo-H743zi2 board (should have put that in the first post sorry - I'll update it).

[MEdgerton]

Right I have a partial answer to this.

I have worked backwards and forward through this and shown the below is repeatable. I used GIT so I could easily undo changes and isolate the issue.

Nucleo-H743zi2 comes with USB_OTG_FS configured as default in STM32CubeIDE.

If you use the .ioc to disable this (USB_OTG as set configured by default), the ETH/LwIP stops working.

If you leave it enabled, but do not call MX_USB_OTG_FS_PCD_Init() it does not work.

My conclusion is that as a lot of the testing for the ETH/LwIP was probably done with this platform (or with the MX_USB_OTG_FS_PCD_Init() , something in the USB_OTG_FS is configured which lets the ETH/LwIP work.

If you start with a bare device, you probaly won't have configured this, and it won't work.

Now i don't know if its something hardware related, or firmware. I am leaning to firmware. The code runs and throws no errors, so if it was hardware of the USB causing issue, I'd expect to see the firmware fail or not go through te while(1) loop and process LwIP ok.

The fact is that this does work, but the LwIP does not return even a simple ping if this is disabled through the .ioc.

Perhaps there is a shared pin, or one is not being configured (as if I run a working copy and leave it powered and run code without the USB init call it still works).

So its only after a power cycle when the USB is not configured I fail to get a ping.

This means I can progress my project. But I will now investigare which bit of the USB code lets the ETH/LwIP work as ST need to sort this out.

[MEdgerton]

Further to the above.....

I dug into the GPIO initialiseation and found that if this is run before the MX_LWIP(), which the MX_USB_Init() is, then I get a ping response.

If it is commented out (as below) or after LwIP, then no ping response.

You can see I hve commented it out here.....as well as MX_USB_OTG_FS_PCD_Init()

It seems to m tha something is not being initialised that the ET needs to work, and it is relying on the fact that on the Nucelo boards the USB is typically enabled as a default option, so in a basic test works. Its not until you make your own hardware or don't use the USB that it stops.

I will (probably tomorrow) put up my working code. I haveto remove some customer stuff first to make it generic. It will just be a ping test, but I have shown (at least to myself) this is a good starting test. When the PING works, I have had webserver working (if enabled).

MX_GPIO_Init();

 //MX_USB_OTG_FS_PCD_Init();

//  GPIO_InitTypeDef GPIO_InitStruct = {0};

//  __HAL_RCC_GPIOA_CLK_ENABLE();

//  HAL_PWREx_EnableUSBVoltageDetector();

//

//    __HAL_RCC_GPIOA_CLK_ENABLE();

//    /**USB_OTG_FS GPIO Configuration

//    PA8   ------> USB_OTG_FS_SOF

//    PA9   ------> USB_OTG_FS_VBUS

//    PA11   ------> USB_OTG_FS_DM

//    PA12   ------> USB_OTG_FS_DP

//    */

//    GPIO_InitStruct.Pin = GPIO_PIN_8|GPIO_PIN_11|GPIO_PIN_12;

//    GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;

//    GPIO_InitStruct.Pull = GPIO_NOPULL;

//    GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;

//    GPIO_InitStruct.Alternate = GPIO_AF10_OTG1_FS;

//    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

//

//    GPIO_InitStruct.Pin = GPIO_PIN_9;

//    GPIO_InitStruct.Mode = GPIO_MODE_INPUT;

//    GPIO_InitStruct.Pull = GPIO_NOPULL;

//    HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

//

//    /* Peripheral clock enable */

//    __HAL_RCC_USB_OTG_FS_CLK_ENABLE();

 MX_LWIP_Init();

[Pavel A.]

I have a LwIP & UDP project for Nucleo H743ZI, see at end of the thread:

https://community.st.com/s/question/0D50X0000BK91UeSQJ/h7-udp-example

Built with library v 1.9.0. It is not .ioc based though. Converted from ST demo for other eval. board. No USB, no FMC.

Basically work for me (ping and udp echo).

Will this run on your nucleo?

--pa

[Piranha]

This code is the same as the one CubeMX generates:

https://github.com/STMicroelectronics/STM32CubeH7/blob/5975bffae9358bc2b2890a35a203d940a395efef/Projects/NUCLEO-H743ZI/Applications/LwIP/LwIP_HTTP_Server_Netconn_RTOS/Src/ethernetif.c#L316

The HAL_ETH_BuildRxDescriptors() call releases the Rx buffers back to DMA. After that ST's code returns those Rx data buffers from this function and passes to lwIP for processing. When the next frames come in a short time, the previously received data buffers are damaged while still being processed by lwIP or client software. This behavior is not deterministic and there are plenty of other serious issues. How do you expect such a crippleware to work?

There is no use of "testing" obviously and fatally flawed code.

[Pavel A.]

Of course you're right

this example is not anywhere close to production quality. But in "lab" conditions (isolated eth segment without other traffic) it should respond to ping.

If you've seen my proposal of splitting the ETH driver, all this <questionable> descriptors and buffers manipulations should be moved out of the "HAL" driver to "middleware" so it can be easier fixed and adapted by users. Similar to separation of the USB driver to "HCD" and protocols/classes modules.

[MEdgerton]

Here is my partly working code. Please note I need to confirm the exact MPU settings. I note that some people use 2 MPU units, where other examples use 3.

It also allows data to be buffered by the MPU, which may help stop what the LWIP is processing not being damaged.

This does work for a more complex web page and on a failrly busy network.

For this upload I removed the webpage as it has some customer stuff in it. It worked on JSON/AJAX with lots of javascript displaying graphs and dials etc.

Adding in the IO config for the USB_OTG makes both the ping and web work.

If the device is not powered down and this code is remved from startup and then re-run in debug it remains working.

If the code is removed/commented out, and the power cycled then run, both ping and web stop.

This is tested on the Nucleo-H743zi2 with version V processor.

If someone can test and confirm similar results I would be greatful. So far I cannot see what is causing it. I am about to look and see if there are interupts from the USB OTG that the .ioc did not remove. (edit: I checked and in the .ioc the USB has no interupts enabled). The device is enabled in the .ioc as that is what helped it work. However I do not us the code excecpt the calls as extracted in the main() startup.

[PButt.3]

Hi @MEdgerton​ ,

I tried your project successfully, but if I open the Cube to change the pinout by trying to open the .ioc file, it asks me to migrate the project:

 

If I choose to continue, I get a blank cube application, and if I migrate the project, I am unable to compile the project.

So I tried opening new project using you .ioc file, and add all the .c files to then project, no I am able to compile, but I get hardware fault. I tried looking through all the files and there is no diff. Any idea what I may be doing wrong?

I have attached the migrated project file

Any insight is appreciated.

[MEdgerton]

UPDATE: I think I found one issue. @Pavel A.​ and @Piranha​ thank you for your examples. As .ioc had set the IO speed to Low I had set it to Very High. It needed to be just High.

I thought this had fixed it but I am now not sure as removing the USB_OTG from the .ioc caused a fail with the settings....... I will continue to try and figure this edge-case out.

[MEdgerton]

I have now narrowed it down to the following line of code which will probably help some people:

__HAL_RCC_USB_OTG_FS_CLK_ENABLE();

I found that even if I select CubeIDE to setup the default perherphials, they do not show as configured in the .ioc. However in MX_GPIO_Init() the code is still produced to configure and setup the pins for the default perhephials of the USB OTG and UART3.

I have not yet tried just selecting a bare chip and starting totally from scratch.

At the least this is a useable work-around. But really I'd like to know why I need to enable the USB CLK to get the ETH working properly.

Hopefully this thread will be of use and once this is done, so far I haven't broken the ping or web even with a heavy use pattern. I'll leave it running overnight and see if I can break it.