• State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 181 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 290309
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Device Firmware Upgrade (DFU)

user116812

Hello !

I’m currently working on a project developed with the NRF52, and I’m facing a little problem using the DFU function (Device Firmware Upgrade). As shown in the screenshot enclosed, the first firmware Flash works perfectly (1 application in memory). Using the DFU, the old application is not overwritten, the new one is just written above. I need to keep only one application after the DFU (the last one I’ve flashed with the DFU).

Do you have any solution to the problem?

NB: Apps previewed at the top of memory with the bootloader are normal, I voluntarily write data in the flash memory.

Thanks in advance for your help !

Parents
  • +1

    Hello,

    Are you saying that the application is not updated?

    Unless you did some quite big changes to the bootloader, the application that is running is the one directly above the softdevice. I actually didn't check this before, but perhaps the bootloader doesn't erase the section used to store the application temporary after the DFU process is done. But it is not really a problem. It will use the same area for future DFU.

    Let me try to explain a bit in detail. For simplicity, pretend that application A and application B have the exact same size. A is programmed using a programmer, and we want to DFU to B.

    Before we start, we will have the scenario that is to the left in your first image. Softdevice (with MBR) on the bottom, and application A directly after that. Let us call that area slot 1. Directly after slot 1 we have slot 2, which is currently empty. 

    When we enter DFU mode, it will start receiving the new application, application B, and store it in slot 2. When the transfer is done, we will have the softdevice, and application A in slot 1 and application B in slot 2. At this point it will begin the "swap". It is not really a swap, but it will erase application A from slot 1 and copy application B from slot 2 to slot 1. When the copy is done, it will restart, and run application B from slot 1.

    If you ever perform another DFU, it will erase slot 2, and start over. So even if there is data in slot 2, it is just leftovers from the DFU process. It is not something that will build up and make you run out of flash space. You can verify this by performing another DFU, and see that it will look approximately the same.

    Best regards,

    Edvin

Reply
  • +1

    Hello,

    Are you saying that the application is not updated?

    Unless you did some quite big changes to the bootloader, the application that is running is the one directly above the softdevice. I actually didn't check this before, but perhaps the bootloader doesn't erase the section used to store the application temporary after the DFU process is done. But it is not really a problem. It will use the same area for future DFU.

    Let me try to explain a bit in detail. For simplicity, pretend that application A and application B have the exact same size. A is programmed using a programmer, and we want to DFU to B.

    Before we start, we will have the scenario that is to the left in your first image. Softdevice (with MBR) on the bottom, and application A directly after that. Let us call that area slot 1. Directly after slot 1 we have slot 2, which is currently empty. 

    When we enter DFU mode, it will start receiving the new application, application B, and store it in slot 2. When the transfer is done, we will have the softdevice, and application A in slot 1 and application B in slot 2. At this point it will begin the "swap". It is not really a swap, but it will erase application A from slot 1 and copy application B from slot 2 to slot 1. When the copy is done, it will restart, and run application B from slot 1.

    If you ever perform another DFU, it will erase slot 2, and start over. So even if there is data in slot 2, it is just leftovers from the DFU process. It is not something that will build up and make you run out of flash space. You can verify this by performing another DFU, and see that it will look approximately the same.

    Best regards,

    Edvin

Children
  • 0 in reply to user26071

    Hi,

    Thanks a lot for your response which was very useful. Otherwise, I have a lot of data to store in the flash memory. I'm afraid that with the two apps, I wouldn’t have enough space. Is it possible to dump the memory of the old application data (knowing it size), and to keep only the new needed one ?

     

    Thanks again for your help. I’m verry gratefull !

  • 0 in reply to user116812

    Hello,

    What are you using to store application data? Assuming it is FDS, there is a setting in your application's sdk_condig.h file saying how many flash pages you use for FDS. You should not change this during runtime, since there is no way to know where the records are actually stored (on what page). Remember to set the bootloader's reserved application storage size according to the number of flash pages you are using for FDS. By default they are both set to 3 pages.

    If you are using the default bootloader from the nRF5 SDK (one of the later versions), then in the case where the new application will not fit together with the old one, it will delete the old one before downloading the new one. 

  • 0 in reply to user26071

    Hello,

    Yes, I am using FDS to store data in flash. I just did some data storage and DFU tests, and indeed you were right.This perfectly answers to my initial problem.

    Thank you for your help and your time.

     Best regards.

Related
Terms of service