This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

how to FW update via bootlaoder with nrf52832

Hello Nordic

I am using nrf52832, skd 16.0 , s132 v7, the data with the new FW will be delivered via UART

I wish to understand some issues regarding FW update, after doing some reading

first, if there is an example for a non secure FW update (we have no security issues in our project), for the soc i am working on because i saw there are only examples for 10056 and 10059 and not for 10040 with s132 (with no security that is) ? 

1. First how is it located in memory ? there is a section for the bootloader, section for the softdevice and section for the app? How can I know the address or do I actually don't need to know        them ?

2. When updating FW do I need to update the softdevice separately and then the app or, maybe I don't need to update the softdevice at all when updating FW ? 

3. did I understand correctly: when power up, the bootloader always runs first. Then, if there is no FW update flag, it goes to the softdevice address and then to running the app ?

4. what kind of hardware flag (I guess it's hardware, correct me if I am wrong) the bootloader checks is it a designated pin or maybe a certain register ? (if it’s a pin I am not sure how to do it because all my gpios are taken) ?

5. when bootloader needs to start (FW update flag's up), then it starts coping arriving data (in my case from uart). How can I know where it should be copied to ? and how do I copy it making sure I don't harm or attempt to write over protected flash ?

6. is there an option with the nrf52832 to work with 2 banks in case some updating did not go well ? otherwise I am running over my current app

7. does having a watchdog running in the app effect the FW update in any way ? should the bootloader with the FW update mechanism have a watchdog incase something is not working like a problem with the serial comm, and if such a problem accurse how can I make sure I keep on coping data from where I stopped, beside keeping a trek on number of bytes copied and packets ids and so ?

8. just to make sure I understand, when I want to flush a bootloader to my device I implement a bootloader project (.ses in my case working with Segger) ? if so how do I flash it to the correct location and not just like a regular app or softdevice ?

9. I read everywhere about MBR, sorry but what does MBR stands for (I could not find it in the nrf52832 data sheet) ?

10. Is there a some nrf ready to use pc app for FW updating and if so, is it an open source ?

11. do i need to reset before starting to update the FW , or can FW update accrue while app is running ?

A lot of questions I know, it's my first FW update project, hope it will not be to complicated

Best regards

Ziv

  • Hi,

    Both pc-nrfutil and the DFU Target (as implemented by the bootloader examples) uses the same protocol. So no, there is no need to change the Target depending on what Controller you use (and vice versa), as long as they both use the same protocol.

    Regards,
    Terje

  • hi Tesc

    one more issue regarding the bootloader, i wonder about security issues in the FW side, does the nrfutil app cover some security issues like some tokens or keys or something like that to prevent upgrading of bad FW ? if not, then how should i address this on the FW side ?

    also, is security on the FW is an issue if the new FW file is passed via UART from a PC or some SOM that uses the nrfutil ?

    best regards

    Ziv

  • hi Terje

    why does the sdk example have a FLASH_START = 0x64000 when bootloader acording to documentation starts at 0x78000 ???

  • Hi,

    I am very sorry for the delay.

    Checksums are used in order to ensure that the firmware image is correct, before the new firmware is copied to the final destination or otherwise activated.

    If you use the Secure DFU bootloader, where firmware images must be signed, then you can also guarantee that any new firmware that gets accepted by the device must have been signed by you. (As long as you do not share the private key used for signing the updates with anyone.)

    The firmware itself can be read by anyone handling the zip file containing the upgrade, or intercepts the communication. The security is on validating the firmware, not on keeping the firmware secret.

    ziv123 said:
    also, is security on the FW is an issue if the new FW file is passed via UART from a PC or some SOM that uses the nrfutil ?

    I am not quite sure what you ask for here. Can you elaborate? And what do you mean by "SOM"?

    Regards,
    Terje

Related