Hi,
I am playing around with Chibios on an STM32F427, but I face a hard to diagnose issue.
There are about 4 different threads running, one of which implements a software watchdog. The rest of the threads have to "feed" this watchdog thread to keep the system running.
For some reason, one of the threads blocks somewhere and it does not feed the watchdog. The watchdog thread stops the program execution, giving me the opportunity to investigate. Also I know which of the 3 threads is in error state.
Now I want to know where is execution blocked within this specific thread. How can I get this information?
I tried to check the LR register of the offending thread, but it always points me to the Chibios function that performed the context switch.
Last instruction executed by thread.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Last instruction executed by thread.
Hi,
You could enable the RTOS extension in OpenOCD and then look at the stack trace of that thread. The thread state also should hint at where it is sleeping (semaphore, event or something else). You could also look at the trace buffer and look exactly what happened before the event.
Giovanni
You could enable the RTOS extension in OpenOCD and then look at the stack trace of that thread. The thread state also should hint at where it is sleeping (semaphore, event or something else). You could also look at the trace buffer and look exactly what happened before the event.
Giovanni
Re: Last instruction executed by thread.
Sorry, it wasn't clearly stated. I am looking for ways to automate this.
So when the watchdog times-out, this information should be collected and stored, for later analysis. This is for the cases where the faults occur during the normal operation of the device, and not during development (and thus there would be no debugger connected).
Can this information be extracted somehow from the thread information, or stack? Or only the debugger can perform such analysis?
I actually only need the PC value before the context switch.
So when the watchdog times-out, this information should be collected and stored, for later analysis. This is for the cases where the faults occur during the normal operation of the device, and not during development (and thus there would be no debugger connected).
Can this information be extracted somehow from the thread information, or stack? Or only the debugger can perform such analysis?
I actually only need the PC value before the context switch.
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Last instruction executed by thread.
Hi,
All thread have a pointer to a context structure, registers are stored in there, including PC and LR. The structure is named port_intctx and is defined in the port layer. Note, only non-current threads point to that structure.
You can scan all threads using the registry API.
Giovanni
All thread have a pointer to a context structure, registers are stored in there, including PC and LR. The structure is named port_intctx and is defined in the port layer. Note, only non-current threads point to that structure.
You can scan all threads using the registry API.
Giovanni
Re: Last instruction executed by thread.
This is exactly what I initially tried. As I see only LR is stored in the context structure (at least for the Cortex M4), which I expect to become the new PC when the thread is again scheduled in.
The thing is that LR always points a Chibios function, that one that caused the context switch, and I lose information on what was actually running before that.
I have enabled round robin scheduling, and I know for sure that when the problematic thread is switched out, it hasn't called any Chibios function (I placed an infinite loop in it, just for testing). The round robin scheduler switches out this thread due to its time quantum being all used up. But still LR points chSysSwitch(), and not any instructions that are part of the loop.
Can I extract the correct value of PC anyhow?
The thing is that LR always points a Chibios function, that one that caused the context switch, and I lose information on what was actually running before that.
I have enabled round robin scheduling, and I know for sure that when the problematic thread is switched out, it hasn't called any Chibios function (I placed an infinite loop in it, just for testing). The round robin scheduler switches out this thread due to its time quantum being all used up. But still LR points chSysSwitch(), and not any instructions that are part of the loop.
Can I extract the correct value of PC anyhow?
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Last instruction executed by thread.
Then no, the thread only points to the leaf function stack frame, the rest is upward in the stack at undefined offsets, you cannot access it. the leaf function can be at any depth relative to the application.
The OS is linked with the application so there is no well defined OS-application boundary that could be accessed.
You may try to implement some per-thread state variable, like storing the line number before entering a potentially blocking OS function.
Giovanni
The OS is linked with the application so there is no well defined OS-application boundary that could be accessed.
You may try to implement some per-thread state variable, like storing the line number before entering a potentially blocking OS function.
Giovanni