Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs

Migrating from softdevice to a blank application

Hi,

My current application  is using a softdevice and I need to update it using DFU to an application without softdevice.

The new application must start at 0x0 address, so I will need to erase both softdevice and MBR in the process of upgrade.

I've tried to create a custom application that would be loaded to a device using the regular DFU process and then erase MBR+softdevice and place my next application in their place using fstorage (both softdevice and NVIC variants) from it. In this application I don't use softdevice, it is only used for replacing the old firmware with new one.

I've turned off the APPPROTECT for MBR and softdevice areas in the nRF bootloader.

If I use the softdevice option of the fstorage the erase of softdevice and MBR is unsurprisingly unsuccessful.

If I use the NVIC option of the fstorage, the MBR and softdevice sections are successfully erased, but flash write operations are being stuck. My guess is that the vector table modified by MBR is an issue.

My question is the following:

How would I replace the existing softdevice application by a blank application ( let's say 'blinky', for example) that must start at 0x0 address starting with the DFU?

Thank you.

Parents
  • Hi,

    I must say that this is a quite radical change of firmware and not something you typically would do over DFU, and frankly not something I have ever contemplated before. That said, it should be possible.

    I believe your are on to something with regard to the interrupt vector table being related to the issue. The architecture of the MBR and SoftDevice is based on those forwarding interrupts further up the chain (see Interrupt forwarding to the application). So when you delete the MBR and SoftDevice, you also delete the interrupt vector table, and that will cause great problems. The solution should be to use the Vector Table Offset Register (VTOR) first, so that the CPU uses the vector table from wherever you have placed it.

Reply
  • Hi,

    I must say that this is a quite radical change of firmware and not something you typically would do over DFU, and frankly not something I have ever contemplated before. That said, it should be possible.

    I believe your are on to something with regard to the interrupt vector table being related to the issue. The architecture of the MBR and SoftDevice is based on those forwarding interrupts further up the chain (see Interrupt forwarding to the application). So when you delete the MBR and SoftDevice, you also delete the interrupt vector table, and that will cause great problems. The solution should be to use the Vector Table Offset Register (VTOR) first, so that the CPU uses the vector table from wherever you have placed it.

Children
  • Thank you for your help, Einar!

    With the following flow:

    1.1 Remove the flash protection for MBR and softdevice in the nRF bootloader.
    1.2 Upload 'loader' application that is combined with blinky at an offset using the regular DFU process.
    2.1 In this 'loader' application, set the Vector Table Offset Register manually to the start of application (0x26000)
    2.2 Delete MBR and softdevice
    2.3 Copy the blinky to the 0x0 address
    2.4 reboot

    I've successfully updated my BLE application using DFU to a BLEless blinky 

    Slight smile

    Now my task becomes more complicated, because I actually need to update to an application that is larger than blinky and is larger than 0x26000.

    To my understanding, the 'loader' application must be located at the 0x26000 address, as it is hardcoded in the softdevice. And it will be overwritten by itself and fail, if I do the same as with blinky.

    How would I overcome this?

    I have an idea of another layer between my loader and the MBR+softdevice. In this layer I would just have a jump to the custom address where I would locate the loader application and it will be possible to do this process. Or maybe it's possible to replace the Nordic bootloader that is located at 0x72000 by my custom loader.

  • Hi,

    I your last suggestion makes most sense: replace the bootloader with your loader application. Then you update to that as if it was a normal bootloader update, and it would be started by the MBR. Then adjust VTOR to point to it before you erase the MBR and SoftDevice. That way you have full freedom with everything between address 0 and 0x72000.

    PS: Note that the DFU update you are doing here, replacing everything, cannot be done in a 100% safe way. If you get a reset at the wrong point, the device will be bricked and you will need to program it from a debugger in order to recover.

Related