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

[Ole Morten]

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.

[Mike Thomspon]

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

[Mike Thomspon]

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.

[Mike Thomspon]

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.

[Ole Morten]

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.