• State Verified Answer
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 87 subscribers
  • Views 820 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 352887
Options

OTA/DFU of identical bootloader ZIP package fails to relaunch the new bootloader.

RVM

I am running the boot loader with the default name 'DfuTarg' on a Nordic NRF52840 board very similar to the PA10056.
I download this boot loader to the board, connect to it using NRF Connect app on my Pixel phone, and select the DFU icon.
I then select the OTA DFU file that I created of the same boot loader.
The file gets transferred and validation appears to pass but at the end the Segger IDE stops at a hardware breakpoint at vector 0xA60 (hardware fault?).

I expected the boot loader to simply disconnect, reboot and be prepared again for the next DFU but it ended up with a vector exception to 0xA60.
This is a very repeatable process regardless of how many times I try it.
Before each attempt, I completely erase the flash on the board and re-download the first boot loader program that starts on the board.

I think this is my misunderstanding of the system level workflow.
Does the Nordic OTA+DFU ecosystem support a simple boot loader supporting its own update without an application?

Cheers
RVM

  • 0 in reply to RVM
    RVM said:
    The phone application successfully reboots the buttonless DFU app into boot loader but does not appear to stay connected long enough to perform any data transter (at least does not appear to be doing so). The remote device continuosly keeps disconnecting and the NRF Connect app on my android phone continuously attempts to connect to the DFU target device.

    Is there any disconnect reason given in the log from the phone or target device? Also, are you doing buttonless DFU with our without bond sharing  (see https://docs.nordicsemi.com/bundle/sdk_nrf5_v17.1.0/page/service_dfu.html)?

    RVM said:
    Ten minutes later, I fire it up and scan the BLE target device and it "SHOWS THE NEW BOOTLOADER IS ACTIVE". 

    Does it remain stuck in bootloader DFU mode? It's supposed to time out (2 min by default) and boot back into the application. Also, for my understanding, how is it determined that the new bootloader is executing?

    RVM said:
    This is very strange -- why does the phone app keep attempting to connecting to the BLE device even though the remote has SUCCESSFULLY UPDATED THE BOOTLOADER?

    It sounds strange yes, and I'm not sure I understand what is actually happening in the background here.

    Cheers,

    Vidar

  • 0 in reply to Vidar Berg

    Our application firmware queries the boot loader for its version (i.e. static access to the location of a static FLASH ROM based symbol in the boot loader) and adjusts a bit field in the BLE advertisement it sends out periodically. 

  • 0 in reply to Vidar Berg

    I am trying to get an RTT viewer to connect and display messages from the boot loader and the application, but am not having much luck. I suspect, based on my own understanding of the RTT mechanism, and from snippets of wisdom I have seen around the DevZone and/or the internet in general, that the RTT control blocks are different between the boot loader and application builds and therefore the RTT viewer client gets confused (rightfully so). 

    Can you suggest how I can work around this issue ?

  • 0 in reply to Vidar Berg

    FYI, There is one more thing I want to point out here. 

    I am unable to link and create a 'debug' build of the Nordic boot loader on my NRF52840 board if I stick with the boot loader memory layout as suggested in Nordic memory map i.e. start at 0xF8000.  

    The only way I could get the entire program to link was if I expanded the boot loader to start at 0xF4000 (for NRF_LOG_LEVEL_3) or 0xF1000 (for NRF_LOG_LEVEL_4). This is really problematic at such a late stage in our product lifecycle since we have a history of using the page just below the default boot loader start address as a static, non-volatile, customer facing configuration region. 

  • 0 in reply to RVM
    RVM said:
    I am trying to get an RTT viewer to connect and display messages from the boot loader and the application, but am not having much luck. I suspect, based on my own understanding of the RTT mechanism, and from snippets of wisdom I have seen around the DevZone and/or the internet in general, that the RTT control blocks are different between the boot loader and application builds and therefore the RTT viewer client gets confused (rightfully so). 

    Correct, the RTT buffer is kept in RAM and is not linked to a fixed location, so it is likely being overwritten by the application's startup code. But would it be an idea to just try the original SDK bootloader (debug variant) on a development kit just to check whether the behavior is the same or not? I'm not sure I really understand what you are experiencing now with the bootloader. But I don't think I have seen other reports of this. I definitely haven't experienced it myself.

    RVM said:
    The only way I could get the entire program to link was if I expanded the boot loader to start at 0xF4000 (for NRF_LOG_LEVEL_3) or 0xF1000 (for NRF_LOG_LEVEL_4). This is really problematic at such a late stage in our product lifecycle since we have a history of using the page just below the default boot loader start address as a static, non-volatile, customer facing configuration region. 

    But is this a problem if you are only doing a "debug" build? The release configuration can still have the default start address.

Related
Terms of service