• State Verified Answer
  • Replies 11 replies
  • Subscribers 63 subscribers
  • Views 4257 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?

Parents
  • 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.

Reply
  • 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.

Children
  • 0 in reply to Sensorion

    Hi Sensorion,

    I'm sorry that I didn't think of the issue. It's a known issue that when the size of fds changed, there is a chance that the swap page is not recognized and throw FDS_ERR_NO_PAGES when you call fds_init().

    Currently there isn't a function to format fds pages for the first use. You may need to erase the pages manually using fstorage. We also think of adding an option in the DFU bootloader to erase customer data when doing DFU but it's not implemented.

    For now we suggest to keep the number of pages the same between different firmware version, or only increase not decrease number of pages, should also work.

Related