NetXDuo issues after power loss

[olaan]

Hello,

I have encountered a peculiar problem and I am running out of ideas on what to do next.

I'm working on a project with an stm32H563 mcu and lan8742 phy, using threadX and netXduo.

When the code is first downloaded it runs fine, but after a power cycle it doesn't. Connecting a debugger shows that everything is running as expected except there are no ip_events generated. The condition 

if (ip_events & NX_IP_RECEIVE_EVENT)

 in "nx_ip_thread_entry.c" stops triggering (ip_events never changes.)

The thing is, a few weeks ago everything was working fine, the application started up and ran as expected, it responded to pings and processed incoming UDP - it is still running on two of the boards I prepared back then (and I dare not touch those at the moment).

Now that I do the same thing with any of the other boards, all of which were working previously, the application boots and runs after programming, but if I cut the power and restart, it doesn't. It's the same code checked out from the same repo, compiled on the same computer. I've also tried other computers, both Windows and Mac OS, so it's probably not that. The only thing I know has changed are updates to CubeMX and CubeIDE, but I haven't seen any reports on recent breaking changes.

Any help or suggestions on where to dig would be greatly appreciated.

Cheers,

// Ola

[STea]

Hello @olaan ,

can give us more information about the version of cubeMX/IDE that were working and the newer versions you are working with also I recommend checking the changes that need to be made in the linker files to properly allocate the memories. Check also the pin assignment for Ethernet and if it is according to the board schematics. it will be helpful if you can share about your code and how did you implement the configurations of the Ethernet and ThreadX AND NETX.

BR

[olaan]

Hello @STea and thanks for the reply!

 

 

The last confirmed working firmware was built on March 12. I always update to the latest available version of CubeMX and CubeIDE, so I think it was 6.11 and 1.14, respectively, though that could be wrong - I couldn't find a release date for CubeMX.

I went over the pin assignment as you suggested, and it's the same in the project as on the PCB schematics.

Could you point me to what changes need to be made in the linker files? I've based the project on the Nx_UDP_Echo_Server example for the STM32H563ZIT board and I haven't touched the linker file at all.

I've attached two screenshots from the ThreadX and NetX configurations. What else could be helpful to see?

Cheers,

// Ola

[olaan]

So, a quick update.

 

I installed CubeIDE 1.14 (with CubeMX 6.10) ported the project and now it works as expected. Presumably there is some change introduced in 1.15 / 6.10 that breaks my project, though I'm not sure what it could be.

Cheers,

// Ola

[robmilne]

My experience was similar...

https://community.st.com/t5/stm32-mcus-embedded-software/h5-1-2-0-and-cube-1-5-break-ethernet/td-p/653320

-rob

[olaan]

Spot on. This is my problem exactly. I was pretty sure it was reproducible since I got it consistently on windows and Mac, but you've confirmed it.

Cheers,

// Ola

[STea]

Hello @olaan ,

I confirm the issue, I reported the issue internally.

Internal ticket number: 179408. (This is an internal tracking number and is not accessible or usable by customers).

Thank you.

[RusikOk]

STM32CubeIDE Version: 1.16.1 Build: 22882_20240916_0822 (UTC) - problem is present

I use a board of my own production and I noticed that when entering debugging CubeIDE resets microcontroller 3 times. and the reset signal of the core gets outside and resets lan8742. it surprised me a lot because I don't use reset pin from st-link.

If I press the reset button, lan8742 resets only once and does not respond to ping.

Maybe this will help you

[olaan]

Thank you!

Any ETA on when it will be fixed? I'd rather not update without knowing if my application will work.

Cheers,

// Ola

[STea]

Hello @olaan ,

after further investigation we are unfortunately unable to reproduce your behavior.

if you can share the project to further examen what's happening it would be great.
Juste as a hint, when you opened your project with CubeIDE 1.15 did you perform an STLINK update to your board and if you did, did you change the clock speed because in this update we use clock speed 8.33Mhz and not the older 8Mhz value.
BR 

[olaan]

Hello,

I did all the updates I could find at the time, so the ST-Link should also have been updated.

I have a project which demonstrates the problem. However, when we talked last time, it did not seem like the forum allowed me to upload it. Is there another way I could share it with you?

It is a bit strange that it could not be reproduced on your side. We could consistently recreate the issue by simply creating new projects and including the NetXDuo driver. Are there more recent versions available where it may have been fixed as part of some other issue? I hesitate to update without a reasonable chance it has been fixed.

 

Cheers,

// Ola

[olaan]

A quick update.

I noticed that it actually happens on CubeIDE 1.14 / CubeMX 6.10 too, but much more rarely, about 1-2 / 20 power cycles. On CubeIDE 1.15 / CubeMX 6.11 it happens every time as far as I can tell.

A colleague of mine noticed that the issue did not happen after the device had gotten a new configuration (sent over UART) before starting up. After some experiments, it seems it was the delay that caused the IP stack to work as expected.

The following "fixes" the issue for me. At least I have been unable to recreate it:

 

 info("A timely sacrifice to the goddess of bugs and limitations.\n");
 HAL_Delay(5000);
 info("Continuing in ThreadX\n");
 /* USER CODE END 2 */
 MX_ThreadX_Init();
 /* We should never get here as control is now taken by the scheduler */

 

 

Hope it helps.

Cheers,

// Ola

[aw_von]

Thank you Ola,

   Just ran into this bug, with my implementation using the MQTT addon.  Works just fine under debug, fails otherwise. I was seeing it failing deep within the nxd_tcp_socket_connect call, returning a NX_NOT_CONNECTED thread state for the mqtt client thread.  Given the differences in timing & operation between a debug session and normal, I figured this was some sort of a coherency issue, appreciate you Ola for providing this! 

 

@STea - Please add my experience to the data you have related to this issue.  It would be great if ST could let us know when this is resolved.

[STea]

Hello @aw_von ,

thank you for pointing this out, this is noted.
Regards

[stst9180]

+1: There is an identical behaviour on one of our projects.
@STea: Please try to supply some details to the problem if you've further insights, because I'm also facing (another?) problem which leads to a stopping ethernet connection after a while if a lot of traffic went through. I'm just trying to find out if this may be related as it seems that the NetX stack and driver layer pushes out the packets as expected (without any errors) but the mac will not generate a "TX_EN" assertion. Also an "RX_DV" does not trigger RX-IRQ anymore ( ETH-MAC seems somehow dead )