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]

Hello, I haven't had any luck replicating this with ses 4.52b. I made sure the __heap_lock and __heap_link part of the lib didn't get discarded by the linker. What I remember from earlier experiments with this is that the problem occurred only for some builds and that unrelated code changes could make it work again. So my guess was that it had to do with code alignment. Have you tried with and without code optimization enabled to see if it leads to the same result?

A possible solution is to make SES program the hex output instead and only load the debug information from the .elf output. Could you try that? The screenshots below show the two project settings you would need to change for this.

Program the generated *.hex instead of the *.elf file:

Load debug symbols from *.elf file

mtsunstrum said:

As for 0x00075000, I am not sure who is manipulating that. I assume that is partly from settings.hex, but I don't see DEADC0DE marking ... whatever that means.

It's the magic words used by FDS to tag its allocated flash pages, see Page tag. It's written at runtime by the fds_init(), so that's why you don't see it when the checksum validation fails.

mtsunstrum said:

I don't think it is prudent for us to disable CRC checking. 

 I understand. I wouldn't recommend disabling it for FW going into production. It could make it easier to work with the bootloader during development.

[mtsunstrum]

Thanks Vidar, your magic solved my problem. Setting up SES to program with the hex file, rather than it's default .elf file seemed to solve the problem for me.

I think we have finally gotten to the root of it.

To answer some of your questions:

• It would happen on both Debug (no optimizations) and Release builds
• It would happen only on SES versions greater than 4.12
• It would happen across different nRF52 applications, so did not seem to be related to the nature of the application being built.

Thanks again !

[erk1313]

I just wanted to confirm that when IAR outputs a binary, it did not adhere to word alignment, which caused the CRC to differ compared to nrfUtil. and the crc32 in the SDK .   Had to use srecord to pad the binary first.