Is this processor deterministic?

[Glen M]

I've worked with other integrated radio + ARM processors that were not deterministic, and I would like to know if the Nordic solution is.

What I mean is: Is there a way to grab complete control of the processor and execute a block of code that NOTHING can interrupt (short of a reset pin toggle etc)? This seems like an obvious "well of course that's possible - just turn off interrupts" answer, but on that other processor the radio would occasionally completely stall the processor while it handled its business. There was no way to stop it, and it made writing timing-critical code impossible. It took quite awhile to get the manufacturer to admit that this was indeed happening.

I'd just like to hear from a real expert whether this can happen on the nRF52840.

Thanks!

[RK]

If you turn  off  all interrupts on the nRF chips  then nothing will interrupt you, at all. However this won't actually work if you are using bluetooth because when you turn them back on again, if the softdevice (which runs the bluetooth stack) has missed an interrupt for a time-critical bluetooth operation (and the bluetooth stack is VERY time critical), it will just hardfault on you. So don't do that. Even if your operation is quick, you'll eventually hardfault. 

Nordic does have a Timeslot API where you can request a timeslot of a desired length up to a maximum. The bluetooth stack will find a time it can cede control for that amount of time and call you, during that timeslot you have exclusive control of everything on the chip and can do what you want including turning interrupts off, not that the softdevice has any enabled at that point. You have to give control back within the time you agreed or .. hardfault. Note that the longer the slot you ask for, the longer it may be until the softdevice finds a big enough gap to give you control and IT decides when you get the slot, so you can run your code, but you don't know when will  be able to run it. 

If you're not using bluetooth (or one of the other radio stacks) you can do anything you please.

Generally as bluetooth has very strict timing requirements any uniprocessor running a bluetooth stack in software will need interrupts at the highest level. So if timeslot doesn't work for you, your only other option is two processors. 

[Glen M]

I think this is the answer I needed, but I'd like to dig a little further to make certain.

The issue on that other processor wasn't that we were being interrupted, it was that the radio was directly on the ARM AHB bus and it would cycle-steal from the processor. We use a WS2812 LED (because it's cheap and awesome) on most of our designs that we update a few times per second. It takes 30 microseconds to generate the NRZ waveform it needs and it's got to be very precise or the LED will flicker or display the wrong color. That cycle stealing was enough to mess up our waveform and there was no way to fix it. 

So, I'm just trying to make certain that we won't have that issue again.

If there answer is still "you're fine", would that also be the case if we end up using this part for ZigBee or proprietary radio communications?

Thanks!

[RK]

well that gets a bit more interesting. Let's start with, if the radio isn't doing anything, it's not going to be cycle stealing from the processor. So that's back to either not using the BLE stack (which is probably useless) or using the timeslot API during which the radio is not doing anything, really it's not, you can even use that peripheral yourself. If you're still even thinking of just turning off interrupts entirely, that is not going to work because you absolutely will, eventually, trip up the softdevice timing and it will hardfault. So in either of the two ways in which you can legitimately get full access with no interrupts, the radio isn't doing anything so you have nothing to worry about. 

On the more general question of the AHB bus, just because it's interesting to talk about it. This is documented in the manual. There is an AHB matrix, the CPU and any peripheral with DMA can be a master and RAM is divided into address ranges which can be slaves. I suggest staring at the AHB matrix diagram for a while as there's a lot of information buried in there. The CPU has the highest priority so it always wins. Other peripherals will stall as necessary. RADIO is quite a way down the list. That actually brings up an interesting question about what happens if the RADIO is reading the same RAM slave the processor is doing a lot of writes to and whether that would eventually cause the RADIO to miss data (as it can't really stall). Probably not as data going out of the radio is relatively slow so there's probably lots of time for the RADIO to get enough access for the next byte/word. 

One additional point, as you're talking about total determinism, is processor wait states reading from FLASH vs none from RAM. So if you are running code from FLASH you need to think about wait states, and also whether you have the instruction cache turned on or not. I wrote something ages ago comparing the speed of some piece of code running from FLASH vs RAM with and without the ICACHE, sure it's around somewhere. .. ah it's here

TLDR; use the timeslot API and you'll have the access you need to be fine. Other protocols, don't know, haven't used them.  

[awneil]

Glen M said:

We use a WS2812 LED (because it's cheap and awesome)

but a pain-in-the-proverbial to drive - with its arcane, timing-critical, proprietary protocol.

Note that there are similar products with a proper SPI interface - so you don't have to worry about manually bit-banging precise timing.

eg, https://www.avrfreaks.net/comment/2544771#comment-2544771