nrfutil generates wrong CRC

[XavierYin]

nrfutil settings generate" gives different CRC value from what bootloader  calculates. Besides, I used JLinkExe savebin to dump application from DUT and the calculated CRC matches bootloader's value. It looks like nrfutil is problematic.

macOS 10.14
SDK15
nrfutil version 4.0.0
Segger Embedded Studio 3.5.2

Attached files
https://drive.google.com/open?id=1g2Eo4dLErHefG9S3-j3Nha7JTjOGtNq7

Note:
1. app.elf & app.hex are generated by SES
2. setting_page.hex is generated by:
    nrfutil settings generate --family NRF52 --application app.hex --application-version 3 --bootloader-version 2 --bl-settings-version 1 --no-backup setting_page.hex
3. app_dump is by JLinkExe savebin app_dump 0x26000 0x00010698
4. nrfutil settings display setting_page.hex shows:
Bootloader DFU Settings:
* File: setting_page.hex
* Family: nRF52
* Start Address: 0x0007F000
* CRC: 0x1AEE538E
* Settings Version: 0x00000001 (1)
* App Version: 0x00000003 (3)
* Bootloader Version: 0x00000002 (2)
* Bank Layout: 0x00000000
* Current Bank: 0x00000000
* Application Size: 0x00010698 (67224 bytes)
* Application CRC: 0x243A6A75
* Bank0 Bank Code: 0x00000001
5. crc32 app_dump gives 758d7b9e, which is the same as what I see when debugging bootloader
6. Verify in SES, both by elf or intel hex will pass

[Vidar Berg]

Hi,

In Segger embedded studio, can you try to upload the .hex file instead of the .elf file? I suspect this is may be related to the observation I made here: https://devzone.nordicsemi.com/f/nordic-q-a/37507/buttonless-dfu-debugging-problem/144353#144353 

[XavierYin]

Hi Vidar Berg 
Do you use arm_linker_additional_output_file_gap_fill="0xff" in your .emProject so it fills the gap with 0xff?

By default, without filling gap as all SDK examples, it looks the same either by programming with elf or hex. But with gap filling 0xff I can observe the inserted bytes in hex and the dump will have the same CRC as setting page.

I think the problem is about nrfutil since it generates the same CRC for both version of hex, with or without gap filling. I suspect there nrfutil assumes gaps as 0xff, kind of following the fact that erased regions on flash contains 0xff. Thus whether filling gap with 0xFF makes no difference to it. And the cause for problem is SES programs elf by default and assumes 0x00.

[Vidar Berg]

Hi,

Thanks, I was not aware of this option. However, I've been using the default configuration. Also compared the elf and hex file you gave, they both result in the same data being loaded to flash. 

I was not able to reproduce the CRC error with the hex files you provided. I uploaded the bootloader settings pag and app.hex file in addition to stock bootloader and softdevice. CRC: 0x243A6A75 did match in my case. Do you have any code that could potentially modify data in the application region at runtime? Can you try the default bootloader and see if you get the same result?

Commands I used:

nrfjprog --program softdevice.hex --chiperase

nrfjprog --program bootloader.hex

nrfjprog --program app.hex

nrjprog --program settings_page.hex --sectorerase -r

 

[XavierYin]

I "thought" I was all default as you did. But perhaps I did missed somewhere.
(BTW, I program by SES instead of using nrfjprog. I guess they should have the same effect...

By loading & debugging w/ your setup, together with using both arm_linker_additional_output_file_gap_fill="0xff" and
arm_linker_script_generator_default_fill_pattern="0xff"
I'm now happy working with SES.
(I also used user build steps for setting page)

Sorry that at I'm now chasing the schedule and may not afford to do more experiments at least for a week. Thanks for Vidar Berg. I'll try to get back to this ticket when possible.

[Vidar Berg]

Ok good, so it works with SES now. Just let me know if you want to revisit this when you have more time and try finding the root cause.