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

SDK14.2 DFU power cycle issue

Sensorion

Situation: Trying to upgrade previous versions of the SD and BL (V3.0.0) to (V5.0.0) Problem: device power cycles after a new application is flashed to the device into the V5.0.0 SD and BL.

Steps:

  1. Take target device, including dev board, and program SD3.0.0 and V3.0 buttonless bootloader
  2. DFU an App appropriate for SDV3.0.0 and run it.
  3. DFU the new SD and BL (V5.0.0) package to the device
  4. DFU an App appropriate for SDV5.0.0 and run it

Result of performing all 4 steps is that the device keeps power cycling. If you skip step 2, the procedure works and the device functions as desired.

I am guessing that there is some internal register that is written to during the DFU process in step 2, and that this register is not being updated to accommodate the position changes due to the larger SD.

Is there a work around?

  • 0

    The UICR bit that is different is an indicator that the NFC pins are to be used as GPIO. Not the source of my on going issue.

  • 0

    There are 2 bits different in the 2 cases, have you found what the second bit is about ?

  • 0 in reply to Hung Bui

    Your understanding is correct. But " So maybe the system thinks it is still in a DFU downloading state? " is not correct, if it's still DFU download state, it shouldn't call nrf_bootloader_app_start().

    So you dumped the flash out and can find that the application is at correct location ? And there is no different when you diff the flash if you flash SD+APP+BL (SDv5) except for the swap bank?

    Have you tried testing with our SDK examples as the application, instead of yours ?

  • 0

    The last byte of the sequence is not in the register space and I beleive that this is some form of checksum maybe, generated when the data is read from the target nRF chip. The line I quoted there breaks down to 4 UICR registers:

    • 00000015
    • 00000015
    • FFFFFFFF
    • FFFFFFFE
  • 0

    The error was an application level error not a boot loader error. The boot loaders for both the SD v3.0.0 and SD v5.0.0 work correctly as does the package used to update a target chip from v3 to v5. The error was in the interaction between the FDS initialization in the v3 app and then the v5 app.

    The application I was using for SD v3(App3) declared 8 virtual pages of FDS memory space. The new version based on SD v5(App5) only had 4 pages declared. When App3 was flashed to the chip it initialized 8 virtual pages, 7 data and 1 swap. These pages are not erased during the subsequent DFU processes. When App5 is installed and run it tries to initialize the FDS system and finds 4 initialized data pages but no swap page. This creates a no memory error, which causes a system reset.

    The solution was to set the number of virtual pages in App5 to 8.

    I have not experimented with this but perhaps it is possible that changing the number of virtual pages in this manner could result in the same error even without going through the update process. Also the system should have some means of dealing with the situation where it finds several data pages and no swap page.

Related