• State Verified Answer
  • Replies 3 replies
  • Subscribers 86 subscribers
  • Views 1325 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 224982
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

nRF52 DFU over NBIoT network

mfilipovic

HI, we want to develop DFU over NBIoT network (UDP), and we would like some advice on how to implement that. We are using nRF52832.

Looking at your SDK examples for BLE and UART DFU, we noticed that there is a defined messaging standard, and only thing user needs to do is implement custom transport layer.

Questions:

1)    How does DFU procedure write new application? Does it split the application memory in half and writes the new application bytes into free section and after checking, just switches memory banks?

2)    If we would download the new application (raw bytes, essentially hex file) into flash and then reset into bootloader, what functions do we use in order to 'manually' write bytes to flash and check CRC at the end, effectively bypassing standard DFU protocol? The reasoning behind this is that we have all communication over NBIoT in our application, and moving things into bootloader would mean duplicating code (modem drivers) and maintaining it in both projects.

 

Parents
  • 0

    Hi,

    1) The nRF5 SDK DFU Bootloader can be either dual bank (if here is enough free flash space) or single bank (if there is not enough free flash space). It automatically switched between the two for the application, unless dual banking is enforced. It always uses two banks for bootloader and/or SoftDevice updates. Note that the second bank is only used for temporary storage, the new firmware is always copied to the same location as the old after it has been completely received and verified. (Not doing so would require position independent firmware, which is not something we advise against.)

    2) Yes, you can adopt the bootloader to be a thin bootloader that only verifies the image and activates it (copies it in place). You probably want to do both the pre-validation and post-validation steps from the normal ensuring both that the firmware is of correct version (increasing), for the correct HW, is intact and verify its authenticity. Then activate it in the bootloader. How much of the validation is done in the application and how much in the bootloader is up to you. You can look at the DFU bootloader implmementation to see how it is done there. You can also refer to the ZigBee bootloader in the Thread and ZigBee SDK for an example of a thin bootloader that does something similar.

Reply
  • 0

    Hi,

    1) The nRF5 SDK DFU Bootloader can be either dual bank (if here is enough free flash space) or single bank (if there is not enough free flash space). It automatically switched between the two for the application, unless dual banking is enforced. It always uses two banks for bootloader and/or SoftDevice updates. Note that the second bank is only used for temporary storage, the new firmware is always copied to the same location as the old after it has been completely received and verified. (Not doing so would require position independent firmware, which is not something we advise against.)

    2) Yes, you can adopt the bootloader to be a thin bootloader that only verifies the image and activates it (copies it in place). You probably want to do both the pre-validation and post-validation steps from the normal ensuring both that the firmware is of correct version (increasing), for the correct HW, is intact and verify its authenticity. Then activate it in the bootloader. How much of the validation is done in the application and how much in the bootloader is up to you. You can look at the DFU bootloader implmementation to see how it is done there. You can also refer to the ZigBee bootloader in the Thread and ZigBee SDK for an example of a thin bootloader that does something similar.

Children
Related
Terms of service