Linking for nRF52832-QFAB and SDK11

[ecsfang]

Hi!

We are using nRF52832-QFAB (B0 variant) in one of our projects, and it works fine and well.

We are now in the process of using the nRF52832-QFAB-E0 in the same build, but then we run into problems.

We are aware of the "problem" with B0 variant, which have 512 kB flash and 64 kB RAM, while the E0 only have 256/32.
This should not be a problem since the code is small enough and will fit with not problem.

Since the memory is only half in the E0 variant, the bootloader must be placed in lower memory (0x3nnnn instead of 0x7nnnn), and this could be achived using nrfutil to get a new bootload_setting.hex (using the family setting NRF52QFAB), but we also had to update the file dfu_gcc_nrf52.ld and dfu_types.h, changing all 0x7 addresses to 0x3.

But, anyway we do it, we fail somehow. Ie we see that changing the values we either get the application to work but fota (dfu) will fail:

#define BOOTLOADER_REGION_START             0x0007A000
=> app boot: ok, fota: nok

When changing the address in the .ld/.h files, the dfu seems to work, but then the application wont start:
#define BOOTLOADER_REGION_START             0x0003A000
=> app boot: nok, fota: ok

It seems as if the following test fails:

  if (p_bootloader_settings->bank_0 == BANK_VALID_APP)

So, obviously we have missed something while trying to set up the project to work with nRF52832-QFAB E0 variant.

Could you please help me to show which changes and tools to use to be able to link correctly for the nRF52832-QFAB variant E0 using SDK11, ie only using 256/32 kB of memory?

Best regards,
Thomas

[ecsfang]

Hi Vidar,

Thanks for your information!

I'm still haven't get a good grip on the problem and have some follow upp questions.

You suggested to use memwr to update the BANK_VALID_APP byte (nrfjprog --memwr 0x3A000 --val 1 && nrfjprog --reset), but shuldn't that be address 0x3F000? As far as I can see, the bootloader settings page reside at 0x3F000.

(At 0x3A000 is the byte 0x80, and that can not be changed by memwr without erasing the whole page.)

What is written to that page (0x3F000) is the following:

  :10 F000 00 4188A0B0010000000000000001000000 E5
  :10 F010 00 00000000000000000000000000000000 F0
  :10 F020 00 00000000000000000000000000000000 E0
  :10 F030 00 00000000000000000000000000000000 D0
  :10 F040 00 00000000000000000000000000000000 C0
  :0C F050 00 000000000000000000000000 B4

So, changing 0x41 (which is no valid code bank state eg BANK_VALID_APP) to 0x01 makes the test above pass, but then we stop at the next test which is a crc-check. If we skip these two test all together (by updating the code), then we pass and it seems to work fine again (both application and dfu).

Where does these 92 bytes (0x5C) comes from, ie what is the 0x41 placed at 0x3F000? And is 0x01B0A088 the crc?

So the bootloader_settings content seems to be faulty somehow, but I can't see how ...

Best regards,

Thomas

[Vidar Berg]

Hi Thomas,

ecsfang said:

You suggested to use memwr to update the BANK_VALID_APP byte (nrfjprog --memwr 0x3A000 --val 1 && nrfjprog --reset), but shuldn't that be address 0x3F000? As far as I can see, the bootloader settings page reside at 0x3F000.

Yes, sorry, I meant to say 0x3F000.

ecsfang said:

What is written to that page (0x3F000) is the following:

  :10 F000 00 4188A0B0010000000000000001000000 E5
  :10 F010 00 00000000000000000000000000000000 F0
  :10 F020 00 00000000000000000000000000000000 E0
  :10 F030 00 00000000000000000000000000000000 D0
  :10 F040 00 00000000000000000000000000000000 C0
  :0C F050 00 000000000000000000000000 B4

How was this settings page generated? If it was generated with nrfutil, the first word would be holding a 32-bit checksum value as is required by the secure bootloader, instead of the bank_0 code expected by the legacy bootloader. Here you can see the legacy bootloaders' settings format: bootloader_settings_t(boot validation of app is skipped when bank_0_crc==0)

Assume everything works if you don't program the settings page but only run the --memwr command as I mentioned?

Best regards,

Vidar

[ecsfang]

Hi Vidar,

Just changing the single byte at 0x3f000 doesn't help, since the following bytes are not zero, so a crc-check is done (and fails), and erased it is filled with 0xFF.

But, if I remove from the hex-file the data at 0x3fxxx altogether and replace it with a single "01 00 00 00 00" everything seems to work as expected.

  :0CE05000000000000000000000000000C4
  :05F0000001000000000A
  :020000041000EA
  :0810140000A0030000E003004E
  :00000001FF

So, as you suspected, we probably have some mismatch when generating the settings, ie we generate data for a secure bootloader while we are flashing a legacy bootloader.

How should we use nrfutil with sdk11, since using this seems to generate the bootloader_settings for a secure bootloader?
Is there a flag/argument to use, or should we use and older version of nrfutil?

Best regards,
Thomas

[Vidar Berg]

Hi Thomas,

I verified with the original bootloader example that it's sufficient to write the bank valid flag because at least in my case, both .bank_0 and .bank_0_crc are stored together in the same 4-byte word at 0x3F000 (ie bank_0_crc is set to 0 when writing 0x00000001 to 0x3F000). Is your bootloader project compiled with '--short-enums'?

ecsfang said:

How should we use nrfutil with sdk11, since using this seems to generate the bootloader_settings for a secure bootloader?
Is there a flag/argument to use, or should we use and older version of nrfutil?

 nrfutil has never had support for generating the settings page with the legacy format. Instead, we have instructed users to use nrfjprog as I suggested, or initialize settings structure inside the bootloader code.  Please see the answer to question E in this blog post: https://devzone.nordicsemi.com/nordic/nordic-blog/b/blog/posts/common-faqs-on-dfu.

Another alternative if you want the CRC check is to copy the settings page after a successful DFU and use that in your production.  

Best regards,

Vidar

[ecsfang]

Hi Vidar,

Thanks for your help!

We ended up using the same settings-page as provided with our build for B0-variant (moving it to 0x3F000), and that works - still don't know how to generate that from scratch with the tools provided - but again it works for now with this manual step.

Best regards,
Thomas

[ecsfang]

Hi Vidar,

A followup question on this topic ...

We have a device, where the current units are produced with QFABB0 (512/64), and the new units are produced with QFABE0 (256/32).
Our plan is to have the same software in both devices, and my question is if it is at all possible to FOTA the current (working) devices with the new software, or do we have to manually re-flash the old devices.

The application is basically the same, we have only re-linked everything to fit in the smaller device (e.g. moved bootloader from 0x7 to 0x3).

But, when we try to OTA the current devices it seems to fail, probably because we update in steps (SD, application and bootloader) and probably they become out of sync regardning where things are located.
Is there some way we could FOTA these devices (QFABB0) with new software and move the bootloader etc at the same time so that we could have the same software in all devices?

Best regards,
Thomas

[Vidar Berg]

Hello Thomas,

It's not trivial to relocate the bootloader through an OTA update, unfortunately. Bjørn outlines how it can be done here: https://devzone.nordicsemi.com/f/nordic-q-a/18199/dfu---updating-from-legacy-sdk-v11-0-0-bootloader-to-secure-sdk-v12-x-0-bootloader . Maybe it would be better to just distribute 2 update packages with the 2 different memory layouts.

Best regards,

Vidar