2021-09-07 02:49 AM
When running in Azure RTOS you have to press the Suspend button first when it is in tx_thread_schedule.s -> _tx_ts_wait:
2021-09-07 05:55 AM
Hi Andy,
I tried to re-produce the issue with a ThreadX application without success. Could you describe how you created the application or let me know which example project you are using? Which MCU/Board?
2021-09-07 06:12 AM
2021-09-07 08:20 AM
Hi Andy,
Had a look at the attached project. Not expert on Azure, nor what you hope to achieve :)
I set a bunch of breakpoints before/during/after ThreadX initialization/startup. I hit the breakpoints and then click reset which puts me back to the first line in main(). So for me this works as expected. I assume I miss your point.
Could you elaborate on what you are doing and what you expect to happen?
Looking a little bit at the project you attach I notice that the code generated should put the system in sleep.
It is only the main_usbx_app_thread_entry which is ever allowed to run. And it goes to sleep and seems to disable interrupts. All the other threads are SUSPENDED.
/* The following is the idle wait processing... in this case, no threads are ready for execution and the
system will simply be idle until an interrupt occurs that makes a thread ready. Note that interrupts
are disabled to allow use of WFI for waiting for a thread to arrive. */
__tx_ts_wait:
CPSID i // Disable interrupts
LDR r1, [r2] // Pickup the next thread to execute pointer
STR r1, [r0] // Store it in the current pointer
CBNZ r1, __tx_ts_ready // If non-NULL, a new thread is ready!
So the application is stuck here.
Some information sharing in case others want to learn. CubeIDE contains RTOS debug tools for ThreadX.
Window > Show View > ThreadX > ThreadX ....
These views works with any debugger back-end without having to set any check-boxes in the debug configuration. There are however some #defines required in order for ThreadX to build the kernel with the right hooks. See CubeIDE user guide. But should be OK for CubeMX generated project and Microsoft GitHub examples too..
If you need to examine the stack of all existing threads in the RTOS (inspecting local variables etc), you can enable the RTOS Proxy in the debug config. Word of caution. This feature is currently conflicting with Live Expressions feature. So these features are right noe mutually exclusive. Work on-going...
The feature also works for any debug back-end. Segger in your case...
Enable like this RTOS Proxy:
When doing so the Debug view, Variable view, Registers view, etc will show thread context related data.
Hope these features help to learn how to use ThreadX and the various thread synchronization mechanisms.
Andy, this probably still does not explain your original question. But maybe it helps you to find the issue...
2021-09-08 04:34 AM
Hi Marcus
All I was after is the button that if pressed while running works like it used to do, which was stop the CPU and reset it.
Thanks
Andy.