Is it safe to change interrupt handler for GPIOTE while using softdevice ?

[David-Taille]

Hi,

While trying to measure timings with input captures and pin interrupts, I noticed that the SDK-provided pin changed event is very slow : by the time my handler starts running, the signal level has changed...

I then discovered https://devzone.nordicsemi.com/f/nordic-q-a/54956/copying-vector-table-to-ram-unknown-function-at-0x00000000 and managed to set my own handler for GPIOTE.

Works fine : i typically have a max delay between TIMER0 capture and handler start of ~3us with 1 sensor, and ~70us with 3 sensors.

I then tried to make those measurements while using softdevice (s140) to send out the numbers through BLE.

If measurements are performed within a timeslot, everything seems to work properly, including with the interrupt vector moved to RAM and with my custom GPIOTE handler.

So far so good, but running a couple of examples for a few hours is not enough to uncover all possible problems.

So my question is : do yo see any problems moving the vector table to RAM and tweaking handlers while using softdevice ? or can you confirm this is safe ?

Thanks in advance,

David

[Jørgen Holmefjord]

Hi,

I would have to check your questions with the softdevice team, but first I would like to get some more details about your use-case and issue to see if we can suggest some other solution.

I noticed that the SDK-provided pin changed event is very slow : by the time my handler starts running, the signal level has changed...

Which exact code/library/mechanism are you using for this, and what delay are you seeing? There is some interrupt latency running through the MBR/softdevice, but this should be less than 4 us.

While trying to measure timings with input captures and pin interrupts,

Are you measuring timing of the inputs, or some timing in the application? GPIOTE can be connected directly to TIMERs through PPI to measure timing/delay in HW, if that could suit your use-case.

Best regards,
Jørgen