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

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

[hmolesworth]

Try relaxing the BLE timing to see if that helps; in sdk_config.h change this line:

#define NRF_SDH_CLOCK_LF_ACCURACY 1 // <1=> NRF_CLOCK_LF_ACCURACY_500_PPM