Laird BL600 and DFU BLE bootloader

[Morgan Redfield]

Hi,

The SDK6.1 bootloader seems to have problems when used on a Laird BL600 module.

I'm using a BL600 with the SDK6.1 and SD7.1. I want to implement the bootloader in SDK6.1 to allow for OTA updates. I've compiled the bootloader in Keil and put both the SD and the bootloader.hex onto the modules using nRFgo studio. I can then connect to the module over BLE and upload new firmware, but the bootloader fails to load that firmware.

I've used gdb to track the issue down to the line "uint32_t err_code = sd_softdevice_disable();" in bootloader.c. When the bootloader gets to this line, gdb jumps to the softdevice: 0x00000750 in ?? ()

It then reboots and starts the whole process over. The bootloader sees that the app I'm putting on the device is valid, it just can't boot it. It seems to be a problem in the softdevice. I've tried this with SD7.0 and SD7.1, and I get the same behavior.

Any idea what might be causing this?

Thanks for your help.

[Stefan Birnir Sverrisson]

Hi

The SDK6.1 should work with softdevice S110 v7.0.0 and second revision of the nRF51822. The question is what hardware revision is on your BL600 module? The BL600 had first nRF51822 revision to begin with. Is there any version number on the BL600 module? If you find one, I recommend to contact Laird technologies in order to find out what nRF51822 hardware revision is on your BL600 module.

Update 27.11.2014 When running the second revision hardware the bootloader in nRF51 SDK 6.1.0 should work with softdevice S110 v7.0.0 and Master Control Panel v3.7.0 or later. I think it should also work for the latest nRF Toolbox DFU for Android and IOS. What central device are you using for the DFU?

[Morgan Redfield]

We got it figured out. It turns out that the app was booting correctly, but then immediately resetting. So the problem was with the app instead of the bootloader.

Interestingly, starting the app through gdb worked properly, but loading the hex file using a bootloader or nRFGo did not work. That's why we never saw the issue before trying with the bootloader. The line that was causing a hard fault was:

NRF_CLOCK->EVENTS_HFCLKSTARTED = 0;