avgoor commented on issue #16133: URL: https://github.com/apache/nuttx/issues/16133#issuecomment-2833440142
@keever50 It is "running", meaning that the active thread is actively reading the SPINLOCK register for acquiring the spinlock (which never happens for some reason). If you unlock the lock (g_cpu_irqlock in this case) by setting it to 0x0 via debugger the OS is getting unstuck and proceeds running the thread further. But then it gets stuck once again in just couple functions call further down the program. In all my testing I was able to escape from this "deadlock" by manually setting the lock to 0x0 or writing to a corresponding SPINLOCK register of RP2350. So at least in my case it's not like a hardfault when CPU is halted. On the other hand I would not expect any other background thread to run in these moment, I doubt that spinning the lock can be preempted by the scheduler (not sure here). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
