Thingy GCC App goes straight to DFU

[jublin]

I've compiled a new app with a new BLE service and module to go along with it (for different work than my other question, I can test this service in a generic LE explorer).

I've used the GCC toolchain to build this project, and it compiles fine.

However, if I flash it (using nrf52DK as Jlink in NRFGoStudio), the Thingy just hangs out in DFU mode until I erase/reflash the release firmware from the site.

Is there a bug in the makefile for projects/pca20020_s132? My project is based off of that, with some added files/functions that have all linked in properly. It'll flash ok with the JLink, but that's it.

[Hung Bui]

No, it's not a bug. It's just the bootloader checks CRC and find that the new application you flash didn't match with the CRC it stores. I would suggest is to erase the bootloader and flash your application. You can flash the bootloader back later after you done with modifying your firmware. Then you can update your firmware using bootloader (OTA update) or writing to bootloader setting to match the CRC.

[jublin]

So would I JUST have the application, or application + softdevice?

[jublin]

I've tried Application only, App + Softdevice, and Softdevice + my own compiled/signed bootloader, making a dfu package of the application, None of them seem to run.

Stock firmware + signed dfu application package doesn't load because of a invalid FW version.

[Hung Bui]

You can choose to flash the softdevice or not if your application need the softdevice or not. My suggestion is to test first with blink an LED for example, make sure it works. Then you can try something else. If it doesn't work, you need to debug it and see where in the code cause the problem.

[jublin]

Thanks for the help. Turns out I was running something out of memory with another service and afterwards trying to load up the DFU service.