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

Firmware upgrade OTA with BL+APP

lynxemi

We have a device with firmware based on 14.2 (with sd-id 0x96) and we're trying to do a DFU over BLE to a firmware base on 15.2 (with sd-id 0xAE).

We can do a firmware update using segger and install the SD, BL and APP (with settings) and have it run correctly.

We can create a package with all the components and using nRF Connect on Android upload the firmware (signed with the correct key). However, this process never runs ... we just land in a situation where LED2 (on the PCA10056) ends up flashing continuously.

Checking the sd-id with a memrd, gives us the correct SD (0xAE), but all the iterations I have tried have ended up in the same place including SD+BL (no APP).

  • 0 in reply to Einar Thorsrud

    OK,

    Here's the latest ...

    1. I used the SDKs 14.2, 15.0 and 15.2 and created Bootloaders without modification all using the same key in debug mode.

    2. The process of upgrading from SD 6.0.0 (0xA9) to SD 6.1.0 (0xAE) with OTA DFU works without any issues.

    3. Both going from 14.2 to 15.0 or 14.2 to 15.2, have the same error as listed earlier.

    <00> info> app: Inside main
    <00> debug> app: In nrf_bootloader_init
    <00> debug> app: in weak nrf_dfu_init_user
    <00> debug> app: In real nrf_dfu_init
    <00> debug> nrf_dfu_settings: Running nrf_dfu_settings_init(sd_irq_initialized=false).
    <00> debug> nrf_dfu_flash: Calling nrf_dfu_flash_init(sd_irq_initialized=false)...
    <00> debug> nrf_dfu_flash: Initializing nrf_fstorage_nvmc backend.
    <00> debug> app: Initializing the clock.
    <00> debug> app: Enter nrf_dfu_continue
    <00> debug> app: Valid SD + BL
    <00> debug> app: Enter nrf_dfu_sd_bl_continue
    <00> debug> app: Enter nrf_bootloader_dfu_sd_continue
    <00> debug> app: SD already copied
    <00> debug> app: Verifying BL: Addr: 0x000F3000, Src: 0x00046E7C, Len: 0x0000AF58
    <00> debug> app: Bootloader not verified, copying: Src: 0x00046E7C, Len: 0x0000AF58

    Now what? (short of having to pull out hardware and flash physically)

    Cheers,
    David

  • 0 in reply to lynxemi

    Hi David,

    This might just be an RTT issue. Have you verified that the bootloader is not actually copied? The reason I ask is that the last line in your log ("<00> debug> app: Bootloader not verified, copying: Src: 0x00046E7C, Len: 0x0000AF58") is the last line that is printed before the MBR copies the bootloader, and the nrf_dfu_mbr_copy_bl() function will only return if it fails.

    When everything goes as planned there will be a reset and the new bootloader will be started after copying. At this point you probably see an RTT issue, as the new bootloader might have placed the RTT buffer in a different address, and in this case you will not see the logging from the new bootloader, since the RTT viewer does not take this into account (it searches the memory for the RTT buffer when it connects, and then assumes this is correct for the rest of the session). This is essentially the same problem as discussed in this and this thread (though in this case there are two variants of the bootloader instead of a bootloader and an application).

    Einar

  • 0 in reply to Einar Thorsrud

    HI Einar,

    Yeah, I guess that could be the case ... but it's ever repeating, and the PCA10056 just sits there with an LED blinking fast (presumably constantly resetting).  I guess it could be constantly failing to copy the BL?!  That snipped above is constantly being spat out.

    > Have you verified that the bootloader is not actually copied?

    Not quite sure at what point this would be seen, and what steps would show this? "Bootloader not verified" is unique to the 14.2 bootloader, so I guess it's still the old bootloader for some reason.

    What do you suggest I try to determine this failure?

    David

  • 0 in reply to lynxemi

    Hi David,

    I see. If you see this repeating, then it is not the RTT problem I mentioned. Then it is the same bootloader starting all over again. This is odd as it should work out of the box without any such issues, and copying should always succeed (at least after a few attempts). Have you tested more than one device, or could there be a faulty device? Have you modified the bootloader in any way? If so, what have you done?

  • 0 in reply to Einar Thorsrud

    Hi Einar,

    These are being tested with no modification to the SDK.  I did it with fresh installs of all and no changes other than dfu_public_key.c.

    I have tested this on 2 x PCA10056 (0.9.0) with the same failure numerous times.  I also have tested it on one of our modules with the same outcome.

    David

Related