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

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

Niclas Heitz — Thu, 21 Feb 2019 11:28:21 GMT

Hello,

we decided to switch to SDK15.0 and therefore postpone this issue.

It seems to no longer happen in SDK15 so I will close this Ticket.

Sorry to all who encounter this problem and can't switch.

Best regards,

Niclas

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

Håvard — Thu, 21 Jun 2018 11:18:20 GMT

Maybe the peer manager logs could be useful.

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

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

Niclas Heitz — Wed, 20 Jun 2018 11:46:00 GMT

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

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

Håvard — Wed, 20 Jun 2018 09:29:46 GMT

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?

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

Niclas Heitz — Tue, 19 Jun 2018 13:52:14 GMT

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:

Setting of Security Parameters for ‘Just Works Pairing’ with bonding.
Establish Connection between the two devices
Start Security Procedure for Bonding
Disconnect
Reestablish Connection between the two devices
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.

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

Håvard — Tue, 19 Jun 2018 12:55:51 GMT

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 :)