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?

[Amanda Hsieh]

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

[danmcb]

"If --sectorerase is given, only the targeted non-volatile memory pages excluding UICR will be erased."

our case seems to contradict this. The hex file defintely has information in the bootloader settings part (

0x0007 F000 on an nRF52832) that was NOT correctly written to FLASH using this flag.

I don't know if that page was programmed but not erased (which would not work because the FLASH driver can only write 1's to 0's) or not programmed at all and what I saw was from the last program cycle. But at any rate, the behaviour we observe does not match your description.

[Amanda Hsieh]

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).

How do you merge the images in the step. 3? Can you provide the commands you used? The mergehex supports to combine up to three .HEX files into one single file, so I usually merge and program the images with the following commands: 

nrfjprog --eraseall
mergehex -m bootloader.hex softdevice.hex -o SD_BL.hex
nrfjprog --program SD_BL.hex --chiperase -r
nrfutil settings generate --family NRF52 --application ble_app.hex --application-version 1 --bootloader-version 1 --bl-settings-version 1 settings.hex
mergehex -m ble_app.hex settings.hex -o merged.hex
nrfjprog --program merged.hex --sectorerase -r

Please let me know this flow help the issue or not. 

-Amanda

[danmcb]

sure. Thanks for responding. We do it in several steps:

nrfutil.exe settings generate --no-backup --family NRF52 --key-file private.key --application my_app.hex --application-version 0 --bootloader-version 0 --bl-settings-version 2 bl_setting.hex
mergehex.exe --merge ../path/to/dfu_bootloader.hex bl_setting.hex --output bl.hex
mergehex.exe --merge my_app.hex bl.hex --output bl_app.hex
mergehex$.exe --merge $(SDK_ROOT)/components/softdevice/s112/hex/s112_nrf52_7.2.0_softdevice.hex bl_app.hex --output the_image.hex

Then:

nrfjprog.exe -f nrf52 --snr $(SNR) --program the_image.hex  --sectorerase
nrfjprog.exe -f nrf52 --snr $(SNR) --reset

Look to me to be the same as your example?

[Amanda Hsieh]

Hi, 

I guess "--no-backup" might cause the issue. Try to remove it. 

--no-backup Do not overwrite DFU settings backup page.
            If not specified, than the resulting .hex
            file will contain a copy of DFU settings,
            that will overwrite contents of DFU settings
            backup page.

-Amanda

[danmcb]

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.