SOLVED: Requirements to run CMSIS RTX RTOS

[bernroth]

Hello all!
What are the basic requirements to successfully run and operate CMSIS RTX RTOS on an ARM CM0 processor?

More details:

I have been working today to implement the CMSIS RTOS in my project on an LPC122x MCU. I am using make, gcc and vim as "IDE".
The linker scripts and startup files have been auto-generated in LPCxpresso. CMSIS header files are used.
I added all source code files from RTOS to the Makefile and everything all-together compiles without error.
As soon following code is run, the MCU hangs and does not make anything else.

osKernelInitialize();
osKernelStart(); <-- causes the system to hang

I have no debugger connected to the target so my insights in the processor are a bit limited.

I am quite sure that some requirement is not met so the operating system can not run and causes an exception.
In my linker script I do not have a section which initialises or defines the heap section in the processor memory space.
This could be an issue but I am not sure.

Has anyone successfully implemented CMSIS RTX RTOS in your own project using GCC? What are the basic requirements, do's and dont's?

Best regards,

Bernhard

[mikerj]

You say the start-up files have been auto-generated; have you checked that the relevant interrupt vectors are pointing to the RTOS functions rather than an empty handler?  SVC, PendSV and SysTick are all likely to be used for an RTOS.

[bernroth]

You say the start-up files have been auto-generated; have you checked that the relevant interrupt vectors are pointing to the RTOS functions rather than an empty handler?  SVC, PendSV and SysTick are all likely to be used for an RTOS.

Thanks for your feedback, the interrupt handlers are declared as weak in the startup_lpc12xx.c which means that another definition somewhere in the code will overwrite/replace them.
In RTX this is done in HAL_CM0.S
Previously the linker complained about my own SysTick_Handler having been still in the code (I removed it now) so IMHO the pointers are correctly set.

In the meantime I have discovered something which might be the cause of the "hang":
The initialisation code has set the priority of EINT1_IRQn to zero, so highest priority:

NVIC_SetPriority(EINT1_IRQn, 0);

In the documentation of FreeRTOS I remember having seen that no interrupt must be declared with an higher priority as the RTOS interrupts.
Maybe this is applicable to CMSIS RTX RTOS as well.
I will try and see what happens tomorrow in the office.

[andyturk]

Has anyone successfully implemented CMSIS RTX RTOS in your own project using GCC?

Yep.

First off, consider using ChibiOS instead. ;-)

Second, get JTAG/SWD working. You can guess at problems for weeks, but a debugger will tell you right away which exception handler you're in.

Third, pay particular attention to how your startup code sets up the stack pointer(s). Also, since RTX wants to dynamically allocate stack space at runtime, make sure that it's able to allocate memory correctly.

osKernelStart is where your thread code will be run, so if it's failing there, it could either be a problem with the kernel itself or something that happened in your code. I'd start looking at whether it's able to make the first context switch correctly. I.e., does it run any of your code or die before?

[bernroth]

First off, consider using ChibiOS instead. ;-)

I am using ChibiOS in other projects with STM32 and it works very well. For this specific project I would like to use CMSIS RTOS (among other reasons are licensing restrictions).

Second, get JTAG/SWD working. You can guess at problems for weeks, but a debugger will tell you right away which exception handler you're in.

Done. The CPU happend to be stuck in "SVCall_Handler" which is spelled wrong in the startup file and should be "SVC_Handler"
After fixing this issue the processor stays in HardFault_Handler - great 

(gdb) bt
#0  0x000000de in HardFault_Handler () at startup/startup_lpc12xx.c:267
#1  <signal handler called>
#2  SVC_Handler () at HAL_CM0.S:230
#3  0x00000250 in SVC_Handler () at HAL_CM0.S:222
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Third, pay particular attention to how your startup code sets up the stack pointer(s). Also, since RTX wants to dynamically allocate stack space at runtime, make sure that it's able to allocate memory correctly.

This is what I am trying to find out. How does the startup code need to get modified to make the dynamic stack allocation work?
I have been using the supplied linker files of the RTOS package from the Templates directory, adjusting the ISR names for my CPU
Then GCC sample startup assembler code and supplied linker script. All not working

Maybe someone whats to share a known working linker file and startup script for ARM CMx so that I can find out the key differences.

[andersm]

I've used CMSIS-RTX on one project, running on an STM32F103. Setting up the project was quite painless using the GNU ARM Eclipse plugin, I don't really remember doing anything except editing the RTX_Conf_CM.c file. My main function calls osKernelInitialize(), then initializes the hardware and creates all threads and other OS objects, and then calls osKernelStart(). Note that osKernelStart() returns, the thread that calls osKernelInitialize() is transformed into the idle task.

How does the startup code need to get modified to make the dynamic stack allocation work?

It doesn't. You edit the OS_PRIVSTKSIZE macro in RTX_Conf_CM.c, the memory pool is allocated as a static array in RTX_CM_lib.h (a bit bass-ackwards, but there you go).

[andyturk]

Done. The CPU happend to be stuck in "SVCall_Handler" which is spelled wrong in the startup file and should be "SVC_Handler"
After fixing this issue the processor stays in HardFault_Handler - great 

(gdb) bt
#0  0x000000de in HardFault_Handler () at startup/startup_lpc12xx.c:267
#1  <signal handler called>
#2  SVC_Handler () at HAL_CM0.S:230
#3  0x00000250 in SVC_Handler () at HAL_CM0.S:222
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

If your release is the same as mine, HAL_CM0.S:230 is an LDMIA instruction that's reloading registers from a saved thread context. If that's crashing, it's probably due to a stack pointer being screwed up in an early context switch.

[bernroth]

Just a short update:

The RTOS works fine now. The reason for it to enter HardFault_Handler was that I must have mixed up the RTOS source 4.70 with HAL_CM0.S of 4.75  Shame on me
Another issue was the "SVCall_Handler" is spelled different in LPCxpresso startup files. The "standard" spelling shall be "SVC_Handler" to work with RTX.

It is indeed not required to setup the linker script or the startup file in any way. The memories like thread stack are setup in RTX_Conf_CM.c and then reserved in the .bss region.

So my final recap:

- Check your interrupt handlers in your startup_xxx.c file and match them with the names in HAL_CM0.S
- Heap memory does not need to be declared in linker scripts, memory is declared only in RTX_Conf_CM.c
- Use all files from the same RTX ZIP archive
- To help bug hunting: Put some LED blink code in the while(1) loop of the exception handlers

Thanks to all for your help and support!