SDK • Re: Single-core FreeRTOS doesn't observe changes stored by an ISR on the other core

it does sound like a bug, probably worth opening an SDK issue...

Will do.

nevertheless, curious what core 1 is stuck on; can you print a stack trace from debugger?

I've tried that, but the core1 frame appears to pointing to NULL at that point:
I get the sense that invoking openocd and/or gdb may have disrupted something, because after doing that, network connections fail and the app is altogether stuck. Before starting them, the lwIP listener and the at-time worker run without a problem, even after the ISR has stopped. The same thing happens when I run the debugger on the versions that don't have the ISR problem.

The at-time worker runs on core1, and after the ISR has stopped I can see that the at-time worker is still functional. So it doesn't appear that core1 is fully crippled.

I have evidence suggesting that the ISR stops running around the time networking has connected to the AP and reached the linkup state. The ISR now saves a timestamp instead of running up a counter, so we can see when it ran last:
Another timestamp gets set just after cyw43_tcpip_link_status() returns CYW43_LINK_UP, shown in this output as t (using the values of to_us_since_boot() for the two timestamps):
As with the counter, the timestamp from the ISR never increases. The two timestamps are less than 1ms apart, which is typical of what I've seen in a few test runs -- the difference has been as low as about 400µs.

Statistics: Posted by slimhazard — Fri Jun 28, 2024 3:43 am

---