GPIOTE Event Handler no longer triggered after connecting to already bonded device

[Niclas Heitz]

Hello,

we recently migrated from SDK12.2 to SDK14.2 and noticed a strange behaviour.

After connecting to a bonded device the nrfx_gpiote_irq_handler is no longer called.

Performing the same actions without a previous bond and instead creating a new bond results in no such behaviour.

Any help would be appreciated.

Best regards,

Niclas

[Håvard]

Hi,

From the top of my head, there is no known correlation that should cause this problem from 12.2 to 14.2. But there have certainly been many improvements between these SDK and if we are lucky it is just some small detail you missed while porting.

Are you using an application close to any of the examples in the SDK?

Is there a "minimum" implementation which can recreate the problem and that you can share with us?

Have you tried outputting any logs to see if they can give any hints of what is going on?

Can I get some rough idea of what the application does? What sort of gpio operations are you performing?

I'm sure we can get to the bottom of the issue together :)

[Niclas Heitz]

The GPIO-Pin is connected to the ChipSelect of our SPI-Master, so it should trigger every time the CS is pulled low. We use this interrupt for our SPI state machine which is handling the flow control, so without it it won't switch to the next state to start the transfer.

In our test case, the application should do the following:

1. Setting of Security Parameters for ‘Just Works Pairing’ with bonding.
2. Establish Connection between the two devices
3. Start Security Procedure for Bonding
4. Disconnect
5. Reestablish Connection between the two devices
6. Start Security

after the reconnection (5), the GPIOTE interrupt is no longer working.

Every command is transfered over SPI, so it has to still be working for the disconnect command and also for the reconnect command. Only the start security command can't be transferred anymore because of the missing interrupt.

[Håvard]

Hi again.

Are you using our serialized setup?

Regardless, is it possible that it is the SPI-master that could be having trouble? I guess you have already confirmed that the CS is in fact pulled low?

It seems that even though the gpio interrupt does not trigger, there is no assert of any kind on the device? It could be interesting to see some debug log, but it sounds like it remains in the connection, correct?

 

 

[Niclas Heitz]

Hi,

we use something similar to your serialized setup.

I checked the SPI Master and everything seems ok he pulls down the CS and then waits for the slave until the timeout is triggered because the slave is not reacting.

The CS switching also seems to be registered by the slave SPI driver since i get the XFER_DONE event when the CS is pulled high again after the timeout, just the gpio is not triggered.

What logs should i enable in SDK_config to give you a good debug log? I already enabled GPIOTE_CONFIG_LOG_ENABLED but alone it does not help very much because nothing is happening after the connect.

Thanks for your help,

Niclas

[Håvard]

Maybe the peer manager logs could be useful.

It's reaching a bit perhaps.. But this issue is a bit hard to attack.