DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Wed, 01 Jul 2015 17:19:26 GMT

The missing NOLOAD might have had something to do with it. I've had to port my application and bootloader from 8.0.0 to 8.1.0. The GPIOTE issue is not trivial to fix with gcc and involved a lot of hacking SDK sources. Unpleasant.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Mon, 29 Jun 2015 14:38:23 GMT

@Eliot: Could you send the hex file you compiled with your toolchain ? I can try to flash it here and compare to the hex file I generated. If you have earlier revision of the chip, it might not work if you don't change the option for concurrent CPU and Radio.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Vidar Berg — Mon, 29 Jun 2015 09:38:24 GMT

DFU support for IAR and GCC was first added in SDK 8.1.0. The assembly routines prior to this release only supported the ARM toolchain. The GPIOTE issue you are mentioning only occurs when combining the app_gpiote module with the gpiote driver. Have you had a chance to try one of my suggestions and see if it solved the problem?

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Fri, 26 Jun 2015 15:49:52 GMT

When flashing the binary I build from your example app, JLink fails with a -1 return code and no error message. Not very helpful. Thanks for taking the time to build these. I can flash them without errors, but when I run them the chip doesn't advertise. I have an xxaa revision chip, which might have something to do with it. It's very hard to debug this on a custom board when my debug LED pins are not the same as the ones on the dev kit.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Fri, 26 Jun 2015 15:37:21 GMT

So SDK 8.1.0 is badly broken for GPIOTE (see devzone.nordicsemi.com/.../) and SDK 8.0.0 is broken for DFU with gcc?

Will there be an SDK 8.2.0? Will it fix both of these issues?

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Fri, 26 Jun 2015 11:56:12 GMT

@Eliot: Could you explain the issue you have with flashing the example ? I don't really get it if you can flash your own hex but not the hex from our example.

Could you let me know which bootloader you are using (SDK version) ? Have you tried the SDK v8.1 bootloader ? As suggested by Vidar, there are some modification added to dfu_ble_svc.c file to support gcc.

You were correct on the app_context_load(), we forgot to mention it in the documentation, we will try to add that. The main purpose is to tell the application to send the service changed notification after it finishes with DFU. But you still should be able to jump to DFU bootloader, with or without that call.

I attached in the answer the 2 hexes, SDK v8.1 bootloader and hrs_dfu application I compiled using gcc (v4.9 2015q1) on Window. I tested and it worked fine.

nrf51422_xxac_s110.hex

bootloader.hex

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Vidar Berg — Fri, 26 Jun 2015 11:43:37 GMT

If the SVC_Handler is implemented incorrectly it could make the bootlaoder fail to enter DFU mode. My suggestion would be to use the official GCC bootloader from SDK 8.1.0 if possible. Alternatively import the df_ble_svc.c (adds support for GCC) file from this release to see if it solves the problem.

You were right that the SDK doc was lacking information regarding the service changed characteristic. In addition to implementing the load app context function as you mentioned, you also need to make sure to allocate space for the app context in device_manager_cnfg.h. I will report this internally, sorry for the inconvenience.

Attached bug fixed linker script as the one provided in the SDK was missing the NOLOAD directive for the .noinit and .bootsettings sections: dfu_gcc_nrf51.ld This issue caused the linker to ("try") place init data in the bootsettings page and .noinit section in RAM.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Thu, 25 Jun 2015 15:07:21 GMT

@Hung, OK, well, regardless, I can't get the example app to flash to a custom board on a Mac. I'm looking for differences between the example app and mine and found that your docs make no mention of the fact that I need to add an app_context_load() function and call it from the device manager event handler. But even with that in place, the call to dfu_ble_svc_set_peer_data() still fails. I'll edit the question again and show as much as gdb can see before that call for the peer data.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Thu, 25 Jun 2015 13:11:09 GMT

@Eliot: The nRF51422 and nRF51822 are the same when you use with S110 (only difference is nRF51422 can run S210, S310). You don't need NO-INIT on the application. Storing bonding information to NO-INIT area (for bootloader) is done by the SVC call.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Thu, 25 Jun 2015 13:00:56 GMT

@Hung That example project isn't much use, sorry. It's for a 51422, the Makefile is Windows-specific (assumes nrfproj.exe is present) and the linker script has no NOINIT RAM section.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Thu, 25 Jun 2015 11:01:41 GMT

@Eliot: Do you have the same issue with the SVC call with the ble_app_hrs_dfu example ? I thought the issue of that example with gcc was fixed from SDK v8.0.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Wed, 24 Jun 2015 16:02:10 GMT

Sure, I'll edit the question and add the code for that, but I've stepped through the SDK sources using debug LEDs and found that there are two problems. The first is that the byte order for the DFU control point value was wrong. I was sending 0x0104 but needed to send 0x0401. The second is that the bond sharing is failing. The call to dfu_ble_svc_set_peer_data() at dfu_app_handler.c L99, which is an SVC, fails. I don't yet have any idea why that fails.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Wed, 24 Jun 2015 09:05:14 GMT

@Eliot: Could you post the code you used to jump to bootloader (bootloader_util_reset() ) ?

Could you try with the example we provided at \examples\ble_peripheral\ble_app_hrs\pca10028\s110_with_dfu to see if you can jump to the bootloader ?

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Eliot Stock — Tue, 23 Jun 2015 16:11:51 GMT

Yes, I have custom linker scripts for both my app and my bootloader, but they are very similar to the dfu_gcc_nrf51.ld in the SDK 8.1.0 example. They both have the last 0x80 of RAM as NOINIT and the peer data variables have the attribute stuff to put them in that section.

RE: DFU control point write, app not restarting into bootloader, gcc, SDK 8.0.0

Hung Bui — Tue, 23 Jun 2015 12:10:04 GMT

@Eliot: I haven't tried the DFU with gcc lately, but have you make sure you used dfu_gcc_nrf51.ld ? There we define the NOINT Ram area that we share between the application and the bootloader.

On KEIL, when I want to do debuging with the bootloader, I still can set a breakpoint in main in bootloader, and wait until the application branch back (by bootloader_start() function in the dfu_app_handler.c ) and can start stepping through the bootloader code from there.

If the GDB debugger wouldn't support that, you can try to turn on a LED at the begining of bootloader main().