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.

[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.

[ovrebekk]

Hi Wojciech

Would you not be able to design some kind of redundancy into your protocol, so that a message could be repeated if it is not acknowledged by the slave?

If you use a sufficiently long connection or advertising interval for the SoftDevice then the number of interrupts should be less. 

Wojciech Puchar said:

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

Funny you should say it, but the T_IFS/interframe spacing value in Bluetooth (the delay between one packet and the next) is specified as (150 +/- 2) us, so in this case a 2 us delay can make a difference ;)

Especially since the T_IFS value will not be exactly 150us to start with. The reason the spec allows up to 2us offset from 150us is to allow for inaccuracies in local oscillators and similar, and from chip to chip you will have a bit of offset. 

Also, while your code might run in 1-2us there is also some added delay for the interrupt itself, meaning the time the stack is interrupted is larger. 

Wojciech Puchar said:

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

Having the source available would allow you to make changes to it, yes, but I don't think it would be easy. 

The problem of making changes to the Bluetooth stack is that you void the qualification we have done to simplify the process of certifying your Bluetooth product. In addition to understanding how the SoftDevice works, making the necessary changes to make it tolerant to interrupts, you would then need to go through the process of qualifying the modified SoftDevice with the Bluetooth SIG. 

Best regards
Torbjørn

[Wojciech Puchar]

I do not expect from you to take responsibility of this software after i modify it.

Just i like to have it available. By using it modified i take responsibility for results.

[ovrebekk]

Hi 

The challenge as I mentioned is the Bluetooth certification. You can't release a Bluetooth product without certifying it with the Bluetooth SIG, and this is not easy or cheap if you are using your own Bluetooth stack, or one that has been modified by you. 

This is a Bluetooth SIG requirement, it is not something we can change. 

In general any request to us for functionality that we don't currently provide is something you need to discuss with one of our sales representatives. If you don't already have a contact in our sales group let me know, and I will forward you the right contact details for a Nordic sales manager in your region. 

Best regards
Torbjørn