Hi,
Is there something the RTX does, that then effectively stops a non-RTX process from running?
I have an old and new bootloader (the old is incumbent on the machines and I'm forced, for the time being, to use it)
I have two builds of the application one with the same RTX OS (single thread, looped every 10ms) and a non-RTOS version that runs the same routine every 10ms, so very nearly identical.
* non-RTX bootloader - RTX application works * non-RTX bootloader - non-RTX application works * RTX bootloader - RTX application works * RTX bootloader - non-RTX application FAILS - hard fault - sadly the one I need! and both work when flashed to the root of flash in the debugger.
I have tried to use the debugger to try and understand the differences but have failed to chase out the issue. Map files look good, and Vector table points where they should. I have tried to strip down the application - while(1) runs, virtually anything else I've tried fails. (One with just CAN ran until another device sent a message even though Rx interrupt was not enabled)
It feels like the bootloader has stored interrupts that when allowed fires an interrupt, that executes from a place that is not code and scribbles across memory. I'm not sure if the debugger is causing the fault, feels like I get different behaviour if the debugger is connected or not.
I'm stuck and out of talent, can you help? Any help would be great.
Background info: STM32F103ZG, RTX version 4.74, Keil 5.11
Please ask if there are other details that would be useful.
Cheers Scott
Eventually - after having to work on other stuff, and getting back to this have now found the issue...
The RTOS sets up the Process Stack, a non-RTOS program does not...
PSP - Process Stack Pointer, MSP - Main Stack Pointer, both are viewable from the Registers window in uVision
A non-RTOS application sets the PSP and MSP to the same address, knowing that PSP will never be used
However if started from a RTOS boot loader, the PSP is set up for use. The non-RTOS application is then running on the Process Stack (in error) and when an interrupt fires (which are run from the Main Stack), the stack is updated and because they are set to the same location, the interrupt overwrites/corrupts the stack. A fault then occurs when the application returns to main function because the Link Register (LR) has been corrupted.
To de-select the use of the Process Stack Pointer the CONTROL needs to be set to zero
__set_CONTROL((uint32_t)0);
Thanks Scott