Bootloader causes BLE_HCI_CONNECTION_TIMEOUT

[flopash]

I'm using the bootloader_secure_ble example, nRF52832, SDK14.0.0, S132 v5.0, IAR 7.80, nRF Connect v2.6.1, and an nRF51 Dongle connection to the host computer (Windows 10). 

I am currently testing by flashing only the softdevice and bootloader onto the nRF52. The device advertises, and I am able to connect to it using the nRF51 dongle in nRF Connect. After about 9 seconds, the device disconnects and nRFConnect reports the reason as: BLE_HCI_CONNECTION_TIMEOUT. 

I've read many of the posts on similar issues, but none have worked so far. I've changed the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL (currently set to 7.5 and 30, respectively--but I've tried 20/40, 100/200, and others) and changed the CONN_SUP_TIMEOUT to 4 seconds. None of these changes had any visible effect.

I tried also connecting to the device using the mobile nRFConnect app on IOS, which appeared to show the same issue (disconnected after >10 seconds). 

I then used a BLE sniffer to see what's going on. It appears the device connects, and is doing handshaking with the host until the peer (my device) stops responding, and the host sends multiple RETRY packets. The device stops responding to the host ~5 seconds after the connection is established, and the retries result in a disconnect ~4 seconds later. 

I have used BLE on this device using my main application with no problems. The bootloader I'm using was ported over from a different nRF52 project I worked on, and they are being used the same way. It's possible the project configuration got corrupted in the porting, but nothing stands out as problematic when I look through the project options. 

I have tried setting breakpoints in the code, however IAR disables them every time I try to set one in the error handler. I have turned off optimizations and added DEBUG to the preprocessor symbols. 

I would appreciate any tips on how to further debug this issue! 

[Edvin]

Hello,

Sorry for the late reply.

so there is no application on your device at this point in time? Did you do a full chiperase in between? "nrfjprog --eraseall"? Did you at one point have an application using the watchdog timer before flashing the bootloader?

Turning off optimization on the bootloader isn't easy. Try to use the Debug project, which has the possibility of logging. 

What SDK version do you use?

What do you mean by: "The bootloader I'm using was ported over from a different nRF52 project I worked on, and they are being used the same way."? Did you use the bootloader project from the SDK?

It sounds like your bootloader suddenly stops responding. Again, what SDK version do you use, and what bootloader project? Do you use bonding in your bootloader? What changes did you do in your porting? 

Best regards,

Edvin

[flopash]

I perform an erase each time I re-program the bootloader. No application is present. 

There was previously an application that had a 30 s watchdog timeout, but I have done a full chip erase in nRFGo Studio since. 

SDK 14.0.0

I started with the example project bootloader_secure_ble. The only modifications I've made are compiling the micro-ecc library, and adding the new public key file. It does not use bonding.

When I tried using the example image bootloader_secure_ble_debug_without_bonds_s132.hex, the device still disconnects when a DFU starts. This worries me that there is somehow a hardware issue. 

Edvin said:

What do you mean by: "The bootloader I'm using was ported over from a different nRF52 project I worked on, and they are being used the same way."? Did you use the bootloader project from the SDK?

We make custom boards, and I have run the same bootloader project successfully on a different custom board (using the same chip and SDK--nRF52832, SDK 14, etc).  

I've attached a snippet from the log from nRF Connect. 

2018-11-26T15:50:00.038Z DEBUG GATTC_EVT_READ_RSP time:2018-11-26T15:50:00.038Z connHandle:0 gattStatus:0 gattStatusName:success errorHandle:0 handle:3 offset:0 len:7
2018-11-26T15:50:00.039Z INFO Attribute value read, handle: 0x03, value (0x): 44-66-75-54-65-73-74
2018-11-26T15:50:25.009Z INFO Disconnected from device --:--:--:--:--:--, reason: undefined
2018-11-26T15:50:25.011Z INFO Performing DFU with file: C:\nRF5_SDK_14.0.0_3bcc1f7\examples\dfu\secure_dfu_test_images\ble\nrf52832\ble_app_buttonless_dfu_without_bonds_s132.zip
2018-11-26T15:50:25.011Z DEBUG Loading zip file: C:\nRF5_SDK_14.0.0_3bcc1f7\examples\dfu\secure_dfu_test_images\ble\nrf52832\ble_app_buttonless_dfu_without_bonds_s132.zip
2018-11-26T15:50:25.026Z DEBUG Found application files: nrf52832_xxaa.dat, nrf52832_xxaa.bin
2018-11-26T15:50:25.027Z DEBUG Creating DFU transport.

[Edvin]

Hello,

Are there any other significant differences between the board that you are testing now and the other custom board that is working?

Does your current board have an LFXTAL? Is the accuracy of the XTAL the same as the on the custom board that is working?

Is it possible to do a sniffer trace of the connection? It should give some more information of what's happening on the air.

Look into the nRF Sniffer.

Best regards,

Edvin

[flopash]

It turns out the bootloader was working fine, but Pin 16 is used by our application and was triggering the bootloader to re-start. Commenting out this check in the bootloader fixed the problem. 

Solution was found here: 

https://devzone.nordicsemi.com/f/nordic-q-a/17455/device-reboots-into-dfu-mode-after-app-update