interrupting softdevice - problem

[Wojciech Puchar]

I need my own input handler procedure that cannot wait.

Interrupt handler is directly attached as GPIOTE_IRQHandler (i don't use your libraries) and takes no more than two microseconds.

I wanted it to be at highest priority. 

As softdevice uses priority 0 and 1 in your nomenclature (0x00 and 0x20 in NVIC_IPRx registers), i write a routing that changes all level 1 (0x20) to level 2 (0x40), and all level 0 (0x00) to level 1 (0x20).

And set IRQ6 (GPIOTE) to level 0 (0x00).

Works and i have lot delays but every few thousands of interrupts i'm getting soft reset.

There are at least 100us between every interrupt. usually much more.

I tried even for test reducing interrupt handler routing to just reset event register - still getting soft resets but much less often.

As you don't provide sources for softdevice, please tell me why it happens.

I see no reason for

1) delaying anything for 1-2us on bluetooth protocol to be a problem.

2) even if it will - i see no reason for resets.

Why this is happening.

[Wojciech Puchar]

Instead of giving me "entusiast achivement" please answer my question.

[ovrebekk]

Hi Wojciech

The SoftDevice is tested and qualified under the assumption that it will use interrupt priorities 0, 1, 4, and 5 exclusively, and we don't support changing this unfortunately. 

Instead I think we should look at whether or not there is an alternative way to implement the functionality you need. 

For instance, it is possible to request a timeslot from the SoftDevice, and for as long as the timeslot lasts you are guaranteed not to be interrupted by the SoftDevice. 

Also, if you explain what you are using the GPIOTE interrupt for I can see if there is some alternative way to implement this. By using the PPI controller together with other peripherals it might be possible to implement your functionality in a way that can run in parallel to the MCU, so that the SoftDevice interrupt won't affect your application. 

Best regards
Torbjørn

[Wojciech Puchar]

While it is clearly possible to just measure pulse length by hardware only, it's definitely not possible to react with some logic.  I want to implement onewire slave as to avoid using separate chip for our hardware which is basically onewire attached BLE module (central). 

What i don't understand is that softdevice code resets when interrupted even for 1-2 microseconds.

It shouldn't work like that.

[ovrebekk]

Hi Wojciech

Wojciech Puchar said:

I want to implement onewire slave as to avoid using separate chip for our hardware which is basically onewire attached BLE module (central). 

How long could one transaction be? 

Is there any way you can have the nRF device inform the other device when it is safe to communicate, so that you can use the timeslot feature to ensure an uninterrupted period of time?

If you have some specification document showing how the interface works it would be interesting to have a look at it, and see if there are any alternative ways to implement this. 

Wojciech Puchar said:

What i don't understand is that softdevice code resets when interrupted even for 1-2 microseconds.

It shouldn't work like that.

The operation of the Bluetooth link layer is very timing critical, and if you miss your TX or RX window by just a couple of microseconds it can be enough to miss it. 

It should definitely be possible to design a Bluetooth link layer that can accept some microseconds of delay from time to time, but in order to support it you need to design this feature into the architecture of the link layer itself. Because the SoftDevice doesn't need to allow for interrupts during the operation of the link layer the designers have chosen to utilize the available time to the maximum. 

Best regards
Torbjørn

[Wojciech Puchar]

What you basically need to implement onewire is:

1) react for falling edge - just start timer here. less than microsecond interrupt handling time

2) react for rising edge - record how long it took after 1 and depending on the value and other circumstances pull (or not) onewire line down for given amount of microseconds (this can be realized by hardware)

That decision could be done with less than 2 microsecond code execution easily.

Measurement error of pulse length may be with few microsecond error but not much more.

but you need to REACT for pin input, not timeslots.

Realisation of onewire master is trivial, onewire slave is not hard either but requires precise timing.

"It should definitely be possible to design a Bluetooth link layer that can accept some microseconds of delay from time to time, but in order to support it you need to design this feature into the architecture of the link layer itself."

I read specs of nRF52832 radio hardware and even used it for non BLE-compatible transmission once.

What exactly requires you to do busy loops or other things like that to handle it?

As far as i read bluetooth specs 2 microsecond delay on sending packet shouldn't make any difference.

10 or more microsecond will do but not 2.

There are enough margin.

STILL - even if this would sometimes (very rarely, if ever) make BLE communication problems, i see no reason why your program crashes because of this.

even if it will rarely miss connection communication window it will be equivalent to transmission error resulting from noise - BLE is resistant to it.

And it will not be a problem for us, especially that onewire bus is not heavily utilized. and it most cases will be used for other devices on the bus when after some bits only part 1) will be done to detect onewire reset and new transmission.

It would be much easier to solve the problem if softdevice code would not be binary only.