CMSIS RTOS with nRF51822 and S110

RE: CMSIS RTOS with nRF51822 and S110

Michael Lamming — Tue, 08 Dec 2015 21:00:20 GMT

rtx-tick.zip - Not there any more.

RE: CMSIS RTOS with nRF51822 and S110

Jason — Tue, 21 Oct 2014 05:07:25 GMT

for you reference: github.com/.../getting_started_with_ucxpresso.nrf.pdf

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Mon, 15 Sep 2014 18:28:51 GMT

A quick look at my simple reference project indicates that all the RTOS modules combined with all features enabled is about 12K of Flash and about 2K of SRAM. The Flash usage can be minimized if you don't include certain features of the RTOS. The SRAM usage varies greatly by project and how many threads you need for the application and whether you need a timer thread. I typically configure about 400 bytes of stack space per thread. Features such as MUTEX and Mailqueues will consume SRAM as well.

RE: CMSIS RTOS with nRF51822 and S110

mira67 — Mon, 15 Sep 2014 18:14:16 GMT

@Mike Thomspon, how much ram/flash space the RTOS consumes in your application? Thanks.

RE: CMSIS RTOS with nRF51822 and S110

Jason — Tue, 05 Aug 2014 13:13:18 GMT

Hi,

For you reference (a C/C++ RTOS framework for nRF51822)

github.com/.../main.cpp

Info:

SoftDevice version: S110 V7.0

nano51822, a Fine Tune Module (Only One SoC nRF51822 inside)

RE: CMSIS RTOS with nRF51822 and S110

Wojtek — Tue, 08 Jul 2014 12:00:47 GMT

www.speedyshare.com/.../rtx-tick.zip no softdevice no RTC0

RE: CMSIS RTOS with nRF51822 and S110

Vincent — Sun, 06 Jul 2014 16:54:15 GMT

Hi all,

Would anyone be willing to post a basic Blinky_RTX example on github that the community could maintain? I'm starting from scratch with nRF51, it would be quite nice to get started! Thanks!

RE: CMSIS RTOS with nRF51822 and S110

Daniel Bayeh — Mon, 03 Mar 2014 23:07:35 GMT

You rock!

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Mon, 03 Mar 2014 19:20:41 GMT

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.

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Mon, 03 Mar 2014 18:15:19 GMT

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.

RE: CMSIS RTOS with nRF51822 and S110

Paul — Sat, 01 Mar 2014 04:58:15 GMT

I tested S210 V2.0.0 and V3.0.0 side by side. V3.0.0 won.:-D

RE: CMSIS RTOS with nRF51822 and S110

Daniel Bayeh — Thu, 27 Feb 2014 23:01:29 GMT

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.

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Thu, 27 Feb 2014 19:27:42 GMT

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.

RE: CMSIS RTOS with nRF51822 and S110

Daniel Bayeh — Thu, 27 Feb 2014 04:48:46 GMT

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

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Thu, 27 Feb 2014 01:41:48 GMT

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.

RE: CMSIS RTOS with nRF51822 and S110

Paul — Wed, 26 Feb 2014 16:54:42 GMT

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

RE: CMSIS RTOS with nRF51822 and S110

Ole Morten — Wed, 05 Feb 2014 10:22:12 GMT

This is actually most likely spot on. There have been fixes to S110 version 6.0.0 to fix its stack pointer use, and I believe this should solve your problem. What threw me of was actually the weird return code you got, since I've seen other things causing that previously. I will however have a go at your project now and see if I can get things running.

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Wed, 05 Feb 2014 01:22:56 GMT

Another update. I've figured out that I'm calling sd_softdevice_enable() from the initial RTOS thread and it's running off the process stack pointer (PSP) when it calls into the function via the SVC interrupt. The softdevice handler, however, assumes the thread was running off the main stack pointer (MSP) and uses the MSP to extract the SVC number -- which of course is wrong as it's on the PSP stack.

It seems the softdevice SVC_Handler should determine which stack was being used when the SVC interrupt was called as it could then correctly pull the SVC number off the correct stack. I'll have to investigate further regarding what the work around for this issue might be.

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Wed, 05 Feb 2014 00:01:54 GMT

Looking more into this I now see that the call to sd_softdevice_enable() results in a call the RTOS provided SVC_Handler() which doesn't correctly pass the SVC call along to the soft device. The return code is a red herring since it doesn't come from the softdevice at all. I'll investigate how to get the RTOS and softdevice properly sharing the SVC interrupt.

RE: CMSIS RTOS with nRF51822 and S110

Mike Thomspon — Tue, 04 Feb 2014 23:05:47 GMT

Thanks for offering to look at this. I've sent you a PM with a link to an RTOS project based on the ble_app_uart project for the NRF6310 dev board you can build and examine. I have no problem sharing the project, but it would be best to post a link after the issue is resolved.

Looking at the CMSIS RTOS use of SVC, it seems to only use SVC 0 which shouldn't conflict with the S110 softdevice. I also verified the versions of the SDK and S110 are correct. I suspect the answer to the issue lays elsewhere. Perhaps in how the RTOS initializes the NVIC or other cortex peripherals.

Thanks,

Mike

RE: CMSIS RTOS with nRF51822 and S110

Ole Morten — Tue, 04 Feb 2014 11:38:09 GMT

Could it be that there is an overlap between the SVC numbers used by the softdevice and the SVC numbers that the CMSIS RTOS uses? As you can see in the S110 SoftDevice Specification, only SVC number 0x0 to 0xF is available to the application.

Also, you should make sure that you use the appropriate header files for the softdevice in question. The easiest way to do this is to make sure that you use the SDK that's built for the softdevice you use, for example SDK 5.1.0 for S110 version 6.0.0 and SDK 4.4.x with S110 version 5.2.1. If you use the wrong one, you may see strange return codes.

If you have further problems, I'd be happy if you could supply the complete application you're working with, so I can do a easy test here. If you don't want to share it here, feel free to create a regular support case.

Edit: Thinking more about this, and reading your comments below, I realized that what you see is as you've found out a consequence of a problem with the stack pointer handling of S110 version 5.2.1. This should however be fixed with 6.0.0, so I'd strongly recommend you to try that instead.