Using SPI after disable SD

RE: Using SPI after disable SD

michalmmz — Sun, 17 Jan 2016 14:15:40 GMT

Thanks for bouth of you!

RE: Using SPI after disable SD

RK — Fri, 15 Jan 2016 01:28:07 GMT

Any sd_* function calls into the softdevice so they will all fail if you're building for softdevice use but have it disabled. So you'd need to modify them all. In the case of the pending IRQ clear, that's easy, however things like sd_nvic_critical_region_* are not, because those you really do want to call into the softdevice.

That gives you two options, either you use the function sd_softdevice_is_enabled() everywhere you 're just about to call an sd_ function and call the equivalent NVIC function (or nothing at all), or just leave the softdevice enabled. Actually 3 options, you could also just write your own SPI driver to do what you need if the changes to the standard one are too extensive.

for the critical enter/exit, you can decide whether you need that at all if the softdevice isn't enabled, you may not. If you do, then just disable IRQs and enable them again.

RE: Using SPI after disable SD

michalmmz — Thu, 14 Jan 2016 21:42:05 GMT

Thank you for answer, but what with other functions in spi_master like sd_nvic_critical_region_enter/exit()? Do i need to change it or delete?

RE: Using SPI after disable SD

Wojtek — Wed, 13 Jan 2016 23:52:19 GMT

Didn't know that RK, thanks for clarification!

RE: Using SPI after disable SD

RK — Wed, 13 Jan 2016 23:15:44 GMT

"because softdevice restricts direct access to NVIC (and lots more) and you cannot use it directly."

That's actually not true. The softdevice doesn't restrict access to the NVIC, and no-longer actually restricts access to much else since recent revisions. Calling via the sd_NVIC_* function just does an extra check that you're not trying to fiddle with an interrupt the softdevice is using. If you know you're not, and the SPI isn't used by the softdevice, it's fine to call the NVIC_ routines directly, and faster too.

RE: Using SPI after disable SD

RK — Wed, 13 Jan 2016 23:12:46 GMT

Probably because you were using the nosd stubs for those functions which are provided in the SDK for simple source compatibility when a softdevice isn't in use and just call the NVIC_ routines directly. Now you're actually using a softdevice you'll be calling the real sd_ ones from one of the softdevice header files and, as Wojtek correctly says, those you cannot call when the softdevice is disabled as they actually call into it via a SVC call.

So either don't disable the softdevice, it doesn't do very much if there's no BTLE stuff going on, or change the code to call the NVIC_ function directly, either conditionally on whether the softdevice is enabled or not, or just call it in all cases.

RE: Using SPI after disable SD

Wojtek — Wed, 13 Jan 2016 23:08:52 GMT

I didn't check that, but that may be true in some cases. Anyway, you should keep with that pattern - sd_ functions only when SD enabled. sd_nvic_ClearPendingIRQ is just alternative to standard CMSIS NVIC_ClearPendingIRQ because softdevice restricts direct access to NVIC (and lots more) and you cannot use it directly.

RE: Using SPI after disable SD

michalmmz — Wed, 13 Jan 2016 22:32:12 GMT

Earlier i made the same project without SD and function sd_nvic_ClearPendingIRQ was calling. Everything was working fine

RE: Using SPI after disable SD

Wojtek — Wed, 13 Jan 2016 22:07:17 GMT

You use SD API calls (the ones that begin with sd_) only when your softdevice is enabled. If you disable your softdevice, you should use non-sd ones, so something like NVIC_ClearPendingIRQ in this case.