how to dfu from bare metal with s132 to zephyr

[ziv123]

Hello Nordic

We have a device, working on nrf52832, with s132 and nRF5 sdk11.0.0, at customers around the world.

It contains a bootloader mechanism that copies a received “.bin” image to memory and then after restart the bootloader checks the GPREGRET register and in dfu is in order it copies the image to the address of application start. 

We wish to move from bare metal (using the softdevice and the old sdk) to zephyr and use the smp service to perform dfu. So there are some question i would like to ask:

Is there a difference between the “.bin” image structure headers / magics etc.  when building with zephyr in comparison to bare metal ?

Is there some difference in memory layout ? 

Zephyr doesn't contain sofdevice but what if a softdevice already exists in memory ?

Are there different address locations and spaces for the application in zephyr and bare metal? 

Does a system running on zephyr also contain an MBR (master boot record) at address 0x00000000 ?  If not, then is it the mcuboot that is in address 0x00000000 ? and does the "west flash --erase" command puts it in address 0x00000000, cause i guess the whole application goes to slot-0, or slot-1 address, is the mcuboot part of the image generated with zephyr ?

How would you suggest upgrading such an old dfu mechanism which currently enables only to update the application (softdevice is fixed since production) to zephyr ?

 

hope to read from you soon

best regards

Ziv

[ziv123]

hi

Edvin said:

See if you can replace your bootloader with the SDK bootloader via DFU. I really think you should look into this before you proceed because it is necessary. And Again, I have not tested this myself. And I can in no way guarantee that this will work at all with the amount of flash on the nRF52832.

well that is the direction .. to first replace the current bootloader .. i will try to understand how the sdk example bootloader replace the bootloader safely .. this will be one approach (if you have some knowledge on that or directions it will be great) 

another possible approach - there is an option to flash only softdevice and application and work without bootloader, in that scenario how does the MBR knows to skip the bootloader and go straight to application or softdevice ? ,does the MBR reads a certain place in flash or is it a configuration of the MBR that,  again, can be done only when using j link to flash and not via BLE ?

hope to read from you soon

best regards

Ziv

[Edvin]

Hello Ziv,

It is the MBR that actually replaces the bootloader when you do a BL update. This is done inside bl_activate in nrf_bootloader_fw_activation.c. What this does is to write to the MBR params page that it should copy the new bootloader (what start address and size it should copy, and then it resets. Then the MBR will read the params page, and copy the bootloader before it starts the new bootloader.

ziv123 said:

and go straight to application or softdevice ? ,does the MBR reads a certain place in flash or is it a configuration of the MBR that,  again, can be done only when using j link to flash and not via BLE ?

The MBR checks the UICR to see whether a bootloader is present or not. If a bootloader is present, it will have the BL's start address. The BL start address is stored in NRF_UICR->NRFFW[0], and the MBR params page address is stored in NRF_UICR->NRFFW[1]. Both of these are used by the MBR and the bootloader (and depending on what SDK your BL is built on, it may differ a bit). But the main point is that it is not straight forward to change any of these without a programmer without risking bricking the devices.

Best regards,

Edvin

[ziv123]

hi Edvin

Edvin said:

But the main point is that it is not straight forward to change any of these without a programmer without risking bricking the devices.

why is it less risky ith a programmer, what additional actions are made by programmer that can not be changed in the code for flash order. 

also, i have tried NRF_UICR->NRFFW[0] = 0xFFFFFFFF

but it does not build 

could not find anyother referance to this reg set in my sdk (11.0)

hope to read from you soon

best regards

Ziv

[Edvin]

Hello,

ziv123 said:

i have tried NRF_UICR->NRFFW[0] = 0xFFFFFFFF

It isn't that easy to manipulate the flash, unfortunately. 

ziv123 said:

why is it less risky ith a programmer

The issue is that without a programmer, you can't update an UICR register. If you have enabled readback protection it is not possible to edit the UICR*. If you have not enabled readback protection, it is possible, but still risky. 

* You can technically write to it, but you can only change bits from 1 to 0, and not the other way around. The reason why it is like this is that the UICR is flash, and in order to write to the same flash area twice, you need to erase the flash page first. It is only possible to erase entire flash pages (the UICR is one flash page) at once, and not only certain addresses. 

This means that if you want to update one UICR register, you need to delete the entire UICR (unless you by chance only need to change 1's to 0's). When doing this, you need to back up the UICR, and if you loose power at this point in time, then the RAM is lost, and you stand left with a blank UICR, which will then not have the NRFFW[0] for the bootloader, and the bootloader will not be reached again. 

In order to erase the UICR, you need to put the UICR in erase mode, which you are not allowed to do when readback protection is enabled. Therefore there is no way to update UICR when readback protection is enabled. 

If you want to modify the UICR you need to erase the UICR using the NVMC peripheral:

NRF_NVMC->ERASEUICR=1;

and wait for the READY event NRF_NVMC->READY. 

Remember that if you loose the UICR page, then you are not able to enter the bootloader again (and the bootloader address is not the only information that is stored in UICR).

Best regards,

Edvin