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

[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 )

[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