BLE Bond GATT Error 133

[moroboshidan]

Hi, I'm using nRF51822 and SDK 12.3.0 and S130 2.0.1 for our development. As I work on bonding the device to the phone, I found out an interesting thing. Sometimes the nRF Connect will print error 8 (GATT CONN TIMEOUT) in the log and disconnect, and when I try to reconnect, it keeps printing error 133 (GATT ERROR) and refuses to connect. Because it happens here and there, it's hard to reproduce this issue and figure out the root of the problem. Right now I can erase the board and flash everything again, but we can't do so when we deliver our products to the customers. Does anyone know what is happening within the PCB? How to avoid this issue? What is the recommended workaround when this (error 8 first and then error 133) happens again? I know error 133 has been a widely discussed issue throughout the forum, but I haven't found a post that speaks to my situation yet. Thank you! 

[Edvin]

Hello,

Have you made sure that you don't have any old bonding data stored in only one of the devices? If the bonding data is mismatching, the bonding will not be successful. I am not sure that this is the issue, but it is worth a shot. To delete the bonding information on the nRF, either call the delete_bonds() function, or delete the flash pages used by the peer manager (check what pages your FDS is using). To delete them from your phone, please go into your bluetooth settings, and "forget device". 

Other than that, the 133 is a very generig error, and it doesn't really give any useful information. 

What does your hardware look like? Is it a DK, or a custom board? If it is a custom board, what does your LFCLK look like? Can you share some screenshots from your layout?

Have you tried to capture a sniffer trace when the connection is not working properly? If not, can you do so? You can use the nRF Sniffer, and upload the .pcapng sniffer trace here.

Best regards,

Edvin

[moroboshidan]

Hi, 

Thanks for reaching out! I'm using a custom board so I don't think I can use sniffer since it requires DK or Dongle. 

Here is a snippet of my configuration of LFCLK. Not sure if this is what you want:

#define NRF_CLOCK_LFCLKSRC      {.source        = NRF_CLOCK_LF_SRC_RC,            \
                                 .rc_ctiv       = 16,                                \
                                 .rc_temp_ctiv  = 2,                                \
                                 .xtal_accuracy = NRF_CLOCK_LF_XTAL_ACCURACY_20_PPM}

Edvin said:

Have you made sure that you don't have any old bonding data stored in only one of the devices?

I'm not sure what you are asking here. I only store the bonding data on my phone and on my PCB. Usually when I disconnect from the phone's side, I can't connect it back and the log says GATT ERROR. Is it because somehow the information from the phone's side got changed and doesn't match the information stored in PCB anymore? 

[Edvin]

Try setting the accuracy to NRF_CLOCK_LF_XTAL_ACCURACY_500PPM.

 

moroboshidan said:

I'm using a custom board so I don't think I can use sniffer since it requires DK or Dongle. 

 That is correct. But when you are sniffing you would require an extra nRF device either way, so it doesn't matter what HW your application is running on. You need an extra DK or Dongle to be able to sniff. 

NB: If you are going to obtain an extra DK/dongle for sniffing, I would recommend something containing the nRF52 series, as these would also be able to sniff 2MBPS. That wouldn't matter in this case, since the nRF51 doesn't support 2MBPS, but in case you need to sniff that in the future. 

moroboshidan said:

I only store the bonding data on my phone and on my PCB.

 Yes, but if it is not stored properly on one of the sides, e.g. your the nRF (your PCB), then they may not be able to connect. 

moroboshidan said:

Is it because somehow the information from the phone's side got changed and doesn't match the information stored in PCB anymore? 

 I don't know. The error 133 doesn't really say much. What does it say on the nRF? Do you see the BLE_GAP_EVT_CONNECTED event?

Either way, try to change the xtal_accuracy first, and see whether that helps. If not, you would need to capture a sniffer trace to see what's actually going on here.