CMSIS RTOS with nRF51822 and S110

[Mike Thomspon]

I'm looking into using the CMSIS RTOS on the nRF51822 with the S110 softdevice which I've used successfully with other Cortex M0 MCUs. I realize the S110 isn't well tested with various RTOS, but documentation indicates it should be possible.

When initializing the softdevice stack with the call to sd_softdevice_enable(), the return code is 0x0D which nrf_error.h indicates is NRF_ERROR_TIMEOUT. However, the documentation for this function in the header files doesn't indicated this is an expected error to be returned. I'm assuming there is some sort of conflict between the RTOS and the softdevice, but it's unclear what the nature of the timeout might be.

Any hints on where I can look to track down the cause of this issue?

Also, if I get the above issue worked out I'm a bit worried about a conflict between the SVC handling by the softdevice and the RTOS. Since the softdevice controls the SVC interrupt handler, I'm assuming it properly chains the SVC calls intended for the RTOS use. Or, is this a bad assumption on my part.

Thanks,

Mike

[Daniel Bayeh]

Hi Guys,

I am just about to start a project with the 51822 and wanted to use the RTX RTOS. But I only have a couple of months for this project and wasn't too sure if I can pull it off in time. But seeing the kind of progress you are making is giving me hope that this could work. One thing I am still not too sure about is the interrupt latency. My understanding is that the max latency can be as high as 5ms+. Do your applications tolerate this latency or how did you deal with this?

Thanks

[Mike Thomspon]

Daniel, I'm assuming that you are concerned about interrupt latency. To be honest, I haven't really considered this too much yet.

The S110 SoftDevice maintains control over all the interrupts and gets first stab at whatever interrupt occurs. It also enforces the interrupt handlers in the application code and RTOS to operate at two specific priorities which are lower than what the SoftDevice operates at. As long as the limitations are honored by the RTOS and application, the RTOS and SoftDevice seem to co-exist fine and the RTOS shouldn't intefere with interrupt handling by the S110 SoftDevice.

With regards to application code running under the RTOS, the S110 SoftDevice will intercept ALL interrupts and redirect those to be handled by the RTOS/application through the secondary interrupt table. This redirection will incur some additional overhead -- probably on the order of a microsecond or so, but I haven't measured it. Because the S110 interrupt handlers operate at a higher priority than the RTOS and application interrupt handlers, the application code will have to be written in such a way to cope with whatever latency may occur under the S110 SoftDevice. The application code would have to factor this in with or without the RTOS.

Currently the application I'm working on consists of three threads under the CMSIS RTOS. One thread services packets as they are passed down by the BLE stack, another thread communicates with SPI peripherals and a third thread runs application code that interacts with the user. Queues are used to pass packets betwen the threads and mutex for protecting critical sections of code. The RTOS internally maintains a fourth thread for OS timer management. Things seem to be working fine so far, but we haven't really started QA work yet to put the system under stress.

I believe what I describe above properly describes the interaction of the RTOS with the SoftDevice, but I would like to hear perspectives from people more familiar or experienced with the S110 SoftDevice.

[Daniel Bayeh]

Mike - thanks so much for your response. I realize now the latency is practically the same regardless of whether an RTOS is used or not, so I guess I will stop worrying about it.

You modified the RTOS to use RTC1 in place of the sysTick. I am assuming you modified the RTX_Conf_CM.c file. How did you set up the last function - os_tick_irqack? I am assuming you pointed the RTC1 exception to the original sysTick handler. Where is the sysTick handler function set up to be an exception handler? This might be a silly question, but this is the first time I am delving into the RTOS internals. Can I just rename the RTC1 handler to sysTick handler and that would do it? Also, why is there an exception handler for the sysTick in the arm_startup_nrf51.s file when there is no sysTick timer?

For the RTC1 conflict with ble_conn_params modue, did you end up using the RTOS's timer? I am curious.

Regards.

[Mike Thomspon]

Daniel,

I indeed used RTC1 in place of SysTick. Basically, in the arm_startup_nrf51.s you need to import OS_Tick_Handler() that is provided by CMSIS RTOS in HAL_CM0.c and use it for the RTC1 IRQ handler. I then created an os_tick_irqack() function that handles the clearing the interrupt as shown below:

// Acknowledge alternative hardware timer interrupt void os_tick_irqack (void) { // Is this a tick condition? if ((NRF_RTC1->EVENTS_TICK != 0) && ((NRF_RTC1->INTENSET & RTC_INTENSET_TICK_Msk) != 0)) { // Clear the interrupt? NRF_RTC1->EVENTS_TICK = 0; } }

If you look in the CMSIS RTOS source in the file HAL_CM0.c you'll find the normal SysTick_Handler() function, but this function is not used on the Nordic so we use the alternate OS_Tick_Handler() in this file which calls the os_tick_irqack(). I think the SysTick_Handler() in the Nordic assembly file is just a legacy left from the standard CMSIS files. It was confusing to me as well.

[Mike Thomspon]

Regarding ble_conn_params.c module, I did convert it to using the CMSIS RTOS timers instead. It was pretty straight forward to re-implement the timeout timer and add mutex protection of the critical data structures that may be called from multiple threads.

[Daniel Bayeh]

You rock!