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

[Paul]

Hi Mike I was in exactly the same shoe you are last April. I traced right into the assembly too. There was no solution from Nordic that time. So I modified the RTOS source and recompiled the CM lib, which fix the stack problem. I got the latest silicon a couple of weeks ago. I haven't got a chance to verify this issue yet. Do you have any updates? Paul

[Mike Thomspon]

With limited testing, it appears that the S110 version 6.0.0 will work successfully with the Keil CMSIS RTOS for our purposes. To get things working I had to substitute RTC1 for SysTick which unfortunately is not on the nRF51 silicon. This in turn caused a conflict with the Nordic timer library which also uses RTC1. I had to rework the ble_conn_params.c library to use the CMSIS RTOS timers because of this, but it wasn't too much work. With these changes things have been working pretty well for us and being able to use threading on the nRF51 will make our application development easier.

[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.