• State Verified Answer
  • Replies 7 replies
  • Subscribers 74 subscribers
  • Views 2689 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 282071
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Please clarify/explain use of --sectorerase with nrfjprog

danmcb

We have some dev code where the workflow is as follows:

1. an engineering version of firmware is loadded to target. The target is erased then programmed in the normal way.

2. various config operations are carried out, and config data is written to FLASH on the target (in an area between the application and the bootloader/dfu config at top of FLASH).

3. the final application is built. Several .hex files are merged at this step : softdevice, application, and also bootloader settings (which live at the top of FLASH).

4. the final application is programmed to target. The device is NOT erased : we call nrfjprog with the "--sectorerase" flag.

We find that when the final app does not boot : the bootloader detects a CRC error. On examining the contents of FLASH, we see that the bootloader settings at top of FLASH do not match the .hex file they were built from - even though step 4 completed without error (log file shows no indication anything did not work).

When we erase the target before step 4, all is well. Bootloader settings are correct and the device boots fine.

Can someone please clarify what "sectorerase" does? Particularly when using a .hex file which has "gaps" between softdevice/app and the settings at top of FLASH? Did we find a bug or do we misunderstand the use of this flag?

Parents
  • 0

    Hi, 

    You can type "nrfjprog -h" command to get the explanation. If --sectorerase is given, only the targeted non-volatile memory pages excluding UICR will be erased. I would suggest to use "--chiperase", then all the available user non-volatile memory, including UICR, will be erased before programming. 

    The Memory layout doc describes the layout of bootload, SD, app, and settings in the memory.  

    Regards,
    Amanda

  • 0 in reply to Amanda Hsieh

    Thank you Amanda. Indeed, removing the nobackup flag seems to fix the issue.

    I don't quite understand how though. Why does the app work after eraseall but not after sectorerase? nrfutil is just generating params for the DFU, how does it influence what happens later at the programming stage in this way?

    what actually *is* the DFU settings backup page?

    Can it be that with this change, the app still finds a CRC issue but then is able to use the "backup" to recover (which would not work if the app had changed between cycles?

    To me, it still seems that nrfjprog not programming the actual data in the .hex file to the target when given the sectorerase flag must be considered a bug - or do I miss something important here?

    Thanks again for helping.

  • +1 in reply to danmcb

    Hi, 

    "--sectorerase" only erase the targeted non-volatile memory pages excluding UICR instead of all the available user non-volatile memory. That means only the required area of the flash will be erased. If there are SD, BL, APP, and Setting in the flash, it now only programs new SD and BL with  "--sectorerase". Only the SD and BL are updated, but the previous APP and Setting are still there and not be erased. As the statement of "--no-backup" describes, it doesn't contain the part to overwrite the backup page. That might cause the "--sectorerase" only erase the area required for the settings image with "--no-backup" (not clear all of the previous settings image part). Therefore, it led to CRC error. I think that might be the reason why removing "--no-backup" in the command can fix the issue. 

    DFU settings backup page is the bootloader settings page which contains sensitive information that should be changed only as a result of authorized firmware upgrades. Because of this, it always keeps a protected backup. The original settings can be left open to allow the application to exchange data with the bootloader (for example, for background DFU). However, the sensitive parts of the settings page are always read from the backup to protect against both malicious and unintended tampering. See Bootloader settings backup.

    Hope this can help. Slight smile

    -Amanda

Reply
  • +1 in reply to danmcb

    Hi, 

    "--sectorerase" only erase the targeted non-volatile memory pages excluding UICR instead of all the available user non-volatile memory. That means only the required area of the flash will be erased. If there are SD, BL, APP, and Setting in the flash, it now only programs new SD and BL with  "--sectorerase". Only the SD and BL are updated, but the previous APP and Setting are still there and not be erased. As the statement of "--no-backup" describes, it doesn't contain the part to overwrite the backup page. That might cause the "--sectorerase" only erase the area required for the settings image with "--no-backup" (not clear all of the previous settings image part). Therefore, it led to CRC error. I think that might be the reason why removing "--no-backup" in the command can fix the issue. 

    DFU settings backup page is the bootloader settings page which contains sensitive information that should be changed only as a result of authorized firmware upgrades. Because of this, it always keeps a protected backup. The original settings can be left open to allow the application to exchange data with the bootloader (for example, for background DFU). However, the sensitive parts of the settings page are always read from the backup to protect against both malicious and unintended tampering. See Bootloader settings backup.

    Hope this can help. Slight smile

    -Amanda

Children
No Data
Related
Terms of service