cancel
Showing results for 
Search instead for 
Did you mean: 

NetXDuo issues after power loss

olaan
Associate II

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

10 REPLIES 10
olaan
Associate II

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