• State Verified Answer
  • Replies 6 replies
  • Subscribers 62 subscribers
  • Views 2362 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 222513
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Problem with bootloader and dfu

Alexc

Hi,

So I've been having a number of issues with getting OTA dfu and the ble secure bootloader working with the 132 softdevice, sdk 14.2 and nrf52832.

So a little context to where I am currently at and what I have tried, I'm currently running everything on a DK just to try get a grasp with everything before moving it to our custom board. So I began with trying the ble secure bootloader example following the instructions on the nordic site. I successfully built the bootloader files, created my own public and private keys, replaced the existing public key with my new one and using the blinky example I made a bootloader settings hex with nrfutil and merged that with the bootloader hex and flashed that to the device which worked fine. I continued to make the dfu package with the blinky example and my private key and transferred it to my phone which brings me to my first issue:

  • when sending the application through OTA dfu it completes fine but then will not actually start the application, LED 3 on the DK remains lit even after resetting the DK the only way to bring it out of this is to reset it while holding button 4 which of course returns it back to dfu mode.

After being stuck on this for a while I decided to just move on, which I realise sounds like i'm jumping the gun a little, and try to implement the buttonless dfu in a simple application that basically just advertises and connects, along with my own bootloader (which is just a copy of the secure ble bootloader without the button stuff), which brings me to my final couple of issues:

  • After flashing my bootloader hex and my application the bootloader seems to be completely ignored, for example I have added code to light LED 3 and wait abit, which has no effect and I can remove  nrf_bootloader_app_start function from main altogether and the application still runs and advertises fine, am I correct in thinking that it should get stuck in bootloader with this removed? I have verified with the nrf intel hex demo (here) that my bootloader and application files are in the correct place. Additionally, looking on nrfgo studio my bootloader isn't recognised as a bootloader, would there be something obvious i'm missing why this wouldn't work when its basically a copy?

  • My final issue is closely related to the previous one upon flashing my bootloader and running my application with buttonless dfu in debug, making sure that the board doesn't erase, the application crashes on the app error check at nrf_dfu_svci_vector_table_set(); with error code 4, meaning it cant find the bootloader.

I would very much appreciate any help,

Many thanks 

Parents
  • 0

    Hi,

    1. Do you see that DFU completes from the nRF side as well? Have you tested with the debug bootloader with RTT logs?

    2. The only reason I could think of for "ignoring" the bootloader is if you for some reason erased the UICR register after flashing the bootloader, or the bootloader .hex file did not contain the bootloader start address in UICR. The reason is that the MBR (residing in the first flash page, starting at address 0) will check the UICR for a bootloader start address. If it is not found (register is all FF's), it will jump directly to the application instead. This is confirmed by the fact that you see nrf_dfu_svci_vector_table_set() returning NRF_ERROR_NO_MEM, which only happens if NRF_UICR->NRFFW[0] is all FF's.

Reply
  • 0

    Hi,

    1. Do you see that DFU completes from the nRF side as well? Have you tested with the debug bootloader with RTT logs?

    2. The only reason I could think of for "ignoring" the bootloader is if you for some reason erased the UICR register after flashing the bootloader, or the bootloader .hex file did not contain the bootloader start address in UICR. The reason is that the MBR (residing in the first flash page, starting at address 0) will check the UICR for a bootloader start address. If it is not found (register is all FF's), it will jump directly to the application instead. This is confirmed by the fact that you see nrf_dfu_svci_vector_table_set() returning NRF_ERROR_NO_MEM, which only happens if NRF_UICR->NRFFW[0] is all FF's.

Children
No Data
Related