KEIL RTX application not getting executed from EMLOAD

Pratheesh P · Jun 22nd 2017, 5:24pm

Hi,

I was trying to jump to my KEIL RTX based application from EMLOAD, but that result into hard fault before branching to the Main().

If I try to jump to sample application without any OS support or with emBOS, FreeRTOS support, then I can jump to the application and it will start executing successfully.

The sample application with RTX is attached. Kindly give me your valuable suggestions.

Regards,
Pratheesh

SEGGER - Oliver · Jun 22nd 2017, 6:05pm

Hello Pratheesh,

I had a look over the CMSIS files included in your project.
The following is a list of things that will most likely not work in this setup:

You are using a minimal CMSIS SystemInit():
The one in use resets registers for CPU clock configuration regardless of their previous state. You could try to use the CMSIS files shipped with emLoad/embOS as running on a reset setup with the minimum base clock is most likely not what you want anyhow.
As I have already written in my last mail, switching away a CPU clock that is currently in use might result in unpredictable behavior.
Reconfiguration of VTOR:
Your minimal SystemInit() sets the vector table offset register to FLASH_BASE. I am unable to find the define in the files you uploaded. If this points to the original base address at 0x08000000, this will overwrite the already correctly set VTOR register set by emLoad. embOS makes sure to set the VTOR register to the correct state during init, based on the address of its own (firmware) vector table.
If you have just used the RTX project as it is, the define FLASH_BASE might point to the wrong vector table.

We try to use the CMSIS files as they come form the CPU vendor but these are not always using optimal settings. It might happen that they do not initialize anything at all or initialize clocks to a value that is not compatible for using USB (requires a clock that is a multiple of 48MHz) or other peripherals.

As you have already checked for yourself, embOS (for sure) and FreeRTOS seem to use a different low level setup.
Can you try to use either the complete CMSIS files from one of these packages (embOS/emLoad preferred) or
the SystemInit() content and try if it allows you to successfully run your application ?

Best regards,
Oliver

Pratheesh P · Jun 23rd 2017, 1:16pm

Hi Oliver,

Thanks for the quick response.

We had a breakthrough today. We noticed that when we commented BTL_NET_ExitCPU() before jumping to the application, there was no hard fault. Our observation is that, in this function 0x80 is written to BASEPRI register so the CPU will not process any exceptions with priority higher than 0x80. In case of our RTX application, SVC exception will be having priority 224 and CPU will not process the exception. Now we are clearing the BASEPRI during start-up of application, and able to boot to our RTX based application. We are doing more testing on it. Will update you later. Could you please give your inputs.

Earlier, we tried with SystemInit()and the system clock configuration as in the embOS project. The IROM1 address was changed to 0x8040000 and VECT_TAB_OFFSET changed to 0x40000. So by this we have verified that the vector table point to correct address.

Thanks
Pratheesh

SEGGER - Oliver · Jun 23rd 2017, 2:21pm

Hi Pratheesh,

Good to hear you were able to figure out what is going on. However, if I understand your solution correct it
has a potential risk to end up in another problem.

You wrote that you are no longer disabling interrupts (done in BTL_NET_ExitCPU()) before jumping into the firmware.
emLoad will switch the vector table to the firmware before executing the jump.

If for any reason an interrupt fires between the switch of the vector table (VTOR register) and initial setup of interrupts in the application, it might happen that old interrupt code from the emLoad gets executed in the wrong context if there is any other interrupt like SysTick that is still active.

Please make sure that this situation can not happen. As this occurs very random, you might not see this problem right now.
It could hit you by any time whenever timing is just not perfect when jumping from emLoad to firmware.

While this might be a solution to you, actually RTX should make sure that everything it requires is setup as expected.

Best regards,
Oliver

Share