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.

[mtsunstrum]

I think I am experiencing the exact same problem, but pretty close to concluding it is not a nrfutil problem.

Rather it seems to be a SES / J-Link flash programming issue.

---

I have been using SES 4.12 for over a year now. Our project has a DFU bootloader, and our application .emproject has been set to do a post-build generation of a setting.hex (CRC) file.

Via SES IDE, we load both application and settings.hex file via Debug->Go

So we can do a nice debug session, in the presence of our DFU Bootloader.

settings.hex is generated our batch file, which uses nrfutil to generate the updated file.

As mentioned, this has worked for a long time now. Flawless.

---

Feeling that I should upgrade SES, I upgraded to SES 4.18.

With NO changes in our project setup, we can no longer properly debug via SES. Code remains in DFU Bootloader due to CRC error.

Only differences between a 4.12 and 4.12 build is the SES provided thumb_crt0.s file. Minor differences. Tried replacing our 4.18's with the 4.12 thumb_crt0.s file ... but no difference.

Tried above discussion on fill patterns. Tried 0x00 and 0xFF. No difference.

Tried newer SES versions ... 4.50, 4.52b. No difference.

Interestingly, I merged my 4 hex files (Bootloader, Softdevice, settings.hex, and our Application), and flashed nRF52 device using nrfjprog, and everything works perfectly. 

---

The ONLY difference hence is how the nRF52 device is programmed. SES IDE will use J-Link utilities, not nrfjprog.

That is why Vidar Berg mentions his nrfjprog method always works.

But that is not convenient when using SES IDE ...

Possible that there is a weakness in the nrfutil calculations that are not tolerant to differences in how J-Link programs flash ... so solution may need to be a co-operative effort with Segger / Nordic.

---

Stepped back to SES 4.12 and works perfectly.

Appears to use J-Link 6.40 version ... whereas newer SES versions use newer J-Link (6.54c, 6.70, ...)

Hence, I have my strong suspicions that there is some subtlety in J-Link's programming that causes CRC error ...

[Vidar Berg]

Hello,

Another difference is that SES loads the *.elf output file instead of the *.hex output. So I still suspect it may be related to padding. Have you tried to read back the flash to see what the difference is?

Comparing flash with nrfjprog:

1. Program the app with SES then run "nrfjprog --memrd 0x0 --n 0x80000 > flash_dump_after_programming_with_ses.txt"

2. Program the same FW with nrfjprog and run "nrfjprog --memrd 0x0 --n 0x80000 > flash_dump_after_programming_with_nrfjprog.txt"

3. Run a 'Diff' on the two text files

Note that there is an option to easily disable CRC boot validation with the newer bootloaders. You just select no boot validation when you generate the settings page.

[mtsunstrum]

Thanks Vidar ... good to know about SES using .elf instead of .hex

Yes, I had on my notes to do a flash readback comparison.

I will revisit this early next week and give that a try.

Thanks, Martin

[mtsunstrum]

OK, I have time to get back at this odd issue.

As mentioned previously SES 4.12 and less works fine when flash programming via SES.

For any SES version greater than 4.12 I see this issue.  But SES 4.12 is kind of unstable, crashes a lot, so looking to move to a newer SES version.

My application memory settings are below:

FLASH_PH_START=0x0
FLASH_PH_SIZE=0x80000
RAM_PH_START=0x20000000
RAM_PH_SIZE=0x10000
FLASH_START=0x26000
FLASH_SIZE=0x52000
RAM_START=0x20002a98
RAM_SIZE=0xd568

In SES, I leave Linker "Default Fill Pattern" and "Additional Output File Gap Fill Value" to 'None'.

Proceeded to use nrfjprog to dump whole contents of Flash memory to see differences.

( I can supply complete dump files if needed)

In Application/Settings.hex file range, only differences are:

---

SES Flash programming of Application/Settings.hex file ... does not pass Bootloader CRC

0x00032310: 47704770 00004770 0002D37D 00000000 

0x00075000: FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 

---

nrfjprog programming of Application/Settings.hex file ... works perfectly

0x00032310: 47704770 FFFF4770 0002D37D 00000000 

0x00075000: DEADC0DE F11E01FF FFFFFFFF FFFFFFFF 

---

Looking at address 0x00032310, map file indicates some code at end of SES libc library functions for heap_lock and heap_unlock.

.text.libc.strlen
0x00000000000322b2 0x60 C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.52b/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi.a(libc2_asm.o)
0x00000000000322b2 strlen
.text.libc.__heap_lock
0x0000000000032312 0x2 C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.52b/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi.a(libc.o)
0x0000000000032312 __heap_lock
.text.libc.__heap_unlock
0x0000000000032314 0x2 C:/Program Files/SEGGER/SEGGER Embedded Studio for ARM 4.52b/lib/libc_v7em_fpv4_sp_d16_hard_t_le_eabi.a(libc.o)
0x0000000000032314 __heap_unlock
0x0000000000032316 __text_end__ = (__text_start__ + SIZEOF (.text))

---

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.

---

If I change Linker "Default Fill Pattern" and "Additional Output File Gap Fill Value" to '0xFF', I can see it fill in some areas with FF.

But the behavior is the same. SES Flash programming fails, nrfjprog is happy.

A diff on their hex files shows the exact same differences as my dump above.

Note that fill 0xFF did not fill FF into address 0x00032314

My guess is this is the root of the issue ...

---

Any help from the flash programming / Bootloader CRC experts is much appreciated.

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

Thanks, Martin

[mtsunstrum]

Note that above information is when using SES 4.52b to program the flash memory (Application/Settings.hex)

If I go back to SES 4.12b and run the same tests, the nrfjprog dump shows they have perfectly matched dump contents byte for byte across the whole 512KB range.