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]

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.