• State Not Answered
  • Replies 4 replies
  • Subscribers 71 subscribers
  • Views 1839 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 112606
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

DFU Unreliable using 110 SD V8, SDK 10.0, GCC 4.9.3

chalecampb

Hello all,

Just to note any versions that need saying, I am using

  • SD 110, V8
  • The 10.0 SDK, freshly unzipped
  • The dual bank BLE bootloader, unmodified
  • Arm GCC 4.9.3 and Eclipse
  • nrfutil version 0.2.1
  • DFU package creation using: nrfutil dfu genpkg --application %s.hex --application-version 0xffffffff --dev-type 0xffff --dev-revision 0xffff --sd-req 0x64 %s.zip
  • Not using bonding
  • SERVICE_CHANGED characteristic is available (and asserted as 1 per the app_hrs).

I've been trying to implement buttonless DFU for the past few days. After reading up, I moved the DFU service-related functionality from the ble_app_hrs example project into my own project. I then compiled and flashed the DFU bootloader from \examples\dfu\bootloader and the V8 110 SoftDevice.

Using this configuration, I was able to successfully flash my application using the bootloader and the nRF Master Control Panel. I incremented the version, tried again, and subsequent DFU updates failed. The logs show that the DFU proceeds up to the point where the file size is written and then the connection is terminated.

I 18:29:52.505 [DFU] Data written to 00001532-1212-efde-1523-785feabcd123, value (0x): 00-00-00-00-00-00-00-00-4C-97-00-00
A 18:29:52.523 [DFU] Firmware image size sent (0b, 0b, 38732b)
D 18:29:52.737 [Server callback] Connection state changed with status: 0 and new state: DISCONNECTED (0)
E 18:29:52.769 [DFU] Error (0x13): GATT CONN TERMINATE PEER USER

I thought maybe I had copied something incorrectly, or the sizes or linker files were incorrect (hence the failure after the size packet) so I went to check the behavior of the provided ble_app_hrs with DFU example. So, I

  1. Compiled the ble_app_hrs
  2. Flashed the bootloader and SD
  3. Created the ble_app_hrs.zip package per the above DFU package command
  4. Flashed the ble_app_hrs.zip successfully to the device
  5. Flashed the ble_app_hrs.zip unsuccessfully to the device, with a similar error as the above (GATT CONN TERMINATE PEER USER)
  6. Subsequent retries, once worked, in maybe a dozen attempts. I can't see a pattern.
  7. I also tried the single bank BLE DFU, and received the same results.

Since this was on development hardware, I then went to check the operation using the nRF51 DK, and received the same response.

I took a tour around the forums and found several posts describing roughly the same events. In general, the DFU routine in MCP will go up to Starting DFU, then it will hang for a while, then it will either return to the tab showing characteristics or disconnect entirely. Since the DFU works perfectly once the bootloader is executing, I have to think that there is something wrong with the DFU app service.

I saw devzone.nordicsemi.com/.../

But, the user found that the bootloader_util.c was previously split into compiler-specific files, and has since been merged into bootloader_util.c, which should include the fixes for the GCC compiler.

I also saw devzone.nordicsemi.com/.../

But, the user was compiling against a broken version of the transport code. I just deleted and refreshed my entire 10.0 SDK source, so that can't be the issue.

The user in devzone.nordicsemi.com/.../

Was using the tools incorrectly to flash the unit, and it was recommended to just reset into the bootloader. Since I have had success once the bootloader is active (DfuTarg is advertised) then I added, at the end of reset_prepare, a hardcoded write to the GPREGRET register with the enter bootloader magic number (0xB1), and found that the program usually hangs at that point, but if it does reset, it seems to jump directly back into the application.

I also made sure that all of the DFU app service setup requirements were met, per the documentation here -> infocenter.nordicsemi.com/.../bledfu_application.html

To summarize the questions,

  1. What is causing the DFU App service to fail to jump into the bootloader? Is there a flag somewhere that I am missing?
  2. Why would the ble_app_hrs example fail? I would have expected the example to work as a reference.
  3. Is it possible that the DFU bootloader is failing during initialization, only when jumping from the application via the DFU app service?

Next debug steps would be to step through the DFU APP service to see if there are any obvious errors. Will comment if I find anything else.

Thanks for any insight you could provide.

-Alex

Related
Terms of service