SDK13.1 secure DFU GATT 133 error

[vigil-jguo]

Hi, I am running into a  connection problem with connecting to the Secure bootloader example in SDK v13.1,  whenever I try to connect I get Gatt 133 error.  To my memory, the bootloader example was fine the last time I visited the topic of OTA, and I remember it working.  I have read posts suggesting connection from android devices can be finicky sometimes and tried to increase the connection parameter update delays, to no success.  Any suggestions?

[MartinBL]

Gatt error 133 is notoriously difficult to debug since it provides very little information by itself. 

1. Is it the peripheral or the central that shows the error?
2. Are you able to get some logging data out of the device? LogCat from Android or using the logger module on the nRF52?
3. Are you able to provide a sniffer log? If you have an extra dev kit from Nordic you can use our nRF Bluetooth Sniffer.  
4. Can you provide any other details surrounding the problem? A step-by-step description of the circumstances leading up to the error for example?
5. What kind of Softdevice and Android phone are you using?
6. Have you tried more than one Android device? What OS versions are they running?
7. Have you tried connecting to simpler out-of-the-box examples to prove that it is related to the bootloader?

[vigil-jguo]

Hi Martin,

Sorry about the late reply, I managed to get it working by stripping the thingy project bootloader.  However, I didn't have the same success from the example secure-bootloader project from SDK v13.1. 

Thank you for the link to the sniffer.  The last time I ran into to this error, I got the impression is only available via the dongle sniffer board, it is great to see that I can use the PCA10040 for toward this purpose.

Do you have any more suggestions on approaching and debugging err 133? or tips on reliable connection (how to avoid err 133)? As it stands, I have found that there are less chance of connection issue if I decrease connection interval.  That is fine for the bootloader, but for our main application, I have the chip set to constantly scanning and advertising and also allows user connection for NUS debug functionality. Currently, I have difficulties establishing connection on demand.

I guess what I am asking is what is the best design approach for getting efficient time slicing of scanning and advertising and getting reliable connection.  If you know of existing article on this, it'd be a great help.

Thanks,

Jian

[MartinBL]

vigil-jguo said:

Do you have any more suggestions on approaching and debugging err 133?

Sniffer. It could be valuable to see which device sent the last packet and what the packet contained. Then we can try to figure out why the other device didn't follow protocol. Also, if possible, turn on all logging features, set compiler optimization to -O0, and define DEBUG and see whether it prints out something useful to your terminal. If the softdevice has issues it might just reset your device (and hence lose the connection), but if you debug with logging it should be possible to capture what goes on.

Regarding efficient time slicing I don't have any good articles, but there is some useful documentation in the Softdevice specification: Scheduling.