A phenomenon occurs in which GPIO input is not possible.

RE: A phenomenon occurs in which GPIO input is not possible.

Susheel Nuguru — Mon, 17 Jun 2024 17:30:21 GMT

Hi SHMoon,

[quote user="yk4224"]

Even the ble_nus_data_send() function executes normally.

However, key data is not received.

[/quote]

Do you have a BLE air sniffer log showing that the the NUS data is transmitted from Peripheral side but the central have not acknowledged it?

- If the BLE air sniffer log have shown that the packet in question is transmitted in the air and the Central have acknowledged it, then something in the central side is wrong. Does Central have nRF or Peripheral have nRF?

- If the BLE packet is transmitted and is clearly shown in the BLE air sniffer log, and the central have not responded, then we need to see why the central is not responding it in the LinkLayer level.

- If the air sniffer shows that the packet is not being transmitted at all, then we need to debug the Peripheral side as to why it queued the packet in the notification but did not send it in the air.

If you can give us the air sniffer log, then we can see which side is the issue (Central or Peripheral)

RE: A phenomenon occurs in which GPIO input is not possible.

SHMoon — Mon, 17 Jun 2024 11:42:58 GMT

[quote userid="124303" url="~/f/nordic-q-a/112082/a-phenomenon-occurs-in-which-gpio-input-is-not-possible"]Additional review was conducted by connecting J-Link.[/quote]

Please check the reviewed part by connecting the J-LInk above.

At first, the key didn't work, so I thought it was a GPIO problem like you said, but

As in the additional review, the key operates normally.

Even the ble_nus_data_send() function executes normally.

However, key data is not received.

In that state, the NUS connection status check confirmed that it was operating normally.

When key data is not transmitted, the NUS connection status check function operates normally.

If you turn off the power on the other side, it is detected on the other side.

***********************************************************************************************************************

Let's organize it again

1) Phenomenon:

- Key input data from Peripheral is not transmitted to Central (of course, 100% is transmitted in normal condition)

- NUS continuously checks the connection status between Peripheral and Central.

2) Conditions for reproducing the problem

- In the pairing state of Central and Peripheral, move the Peripheral to a point with weak reception sensitivity.

It seems to occur during the process of pairing being canceled and proceeding again.

RE: A phenomenon occurs in which GPIO input is not possible.

Susheel Nuguru — Mon, 17 Jun 2024 06:01:43 GMT

Hi SHMoon,

[quote user=""]

1. When the peripheral key is not working and the central power is turned off, the peripheral automatically attempts re-pairing (status check is normal).

2. If you turn on the Central in '1' above, pairing is successful again. However, the peripheral keys still do not work.

3. In the above situation, the only way to restart the peripheral key is to reset the peripheral power.

Can you find out the cause of this?

[/quote]

I am unsure how GPIO key input is related to the pairing. I think it can be a configuration issue of the pin?

Can you start your code in the debugger and after pairing when you see the issue pressing the key which is not working, pause the debugger to see if you can see the context of the current execution?

I am guessing that there is some loop or deadlock in the code in the higher priority which might be masking the GPIO interrupt handling.