• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 8 replies
  • Subscribers 88 subscribers
  • Views 6410 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 204673
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Questions about serial DFU

Liu Tengfei

Dear Support Team,

I’m using nrf52840 with PCA10056 and SDK 14.1.  I want to make a DFU feature using SPI as its transport layer. Could you please help me about the following questions?

1. I could find some Nordic bootloader examples which could be easily used as DFU target, but I did not find any DFU controller examples by C++ code. I noticed that nrfutil(python) and ios/andriod apps that could be able to perform DFU, but I wonder, do you have any c++ source code that could be reused as DFU controller?Or if I want to use DFU service, I have to implement DFU controller logic in C++ myself ?

2. I started with the examples\dfu\bootloader_secure_serial, I think this serial bootloader doesn't need to enable sofdevice at all, but why it need to program the SoftDevice before run this example? (Regarding to the instruction in Nordic docs)

3. Also for the examples\dfu\bootloader_secure_serial, I followed Nordic instructions and everything was right (program softdevice/serial bootloader, make zip package and perform DFU, but I don't merge bootloader setting), I successfully updated an application firmware of examples\peripheral\uart to my PDK through DFU over UART. Since I used debug version bootloader, RTT log showed that nrf_bootloader_app_start with address: 0x23000 after DFU done. However, the uart application couldn't work as expected. I did some test myself, if I directly programmed uart example to my PDK, it worked! Also if I change it's flash location from FLASH (rx) : ORIGIN = 0x0000, LENGTH = 0x100000 to FLASH (rx) : ORIGIN = 0x23000, LENGTH = 0x10000 in the .ld file, and then programmed it to PDK, it also worked! So why it cannot work as expected after successfully DFU and jump to the flash address of 0x23000?

4. Since my device doesn't have any buttons and leds, I have to make an DFU API in DFU controller to trigger DFU while DFU target was running application.

(1) When the host call DFU API, a specified command will be sent to DFU target(I planned to do like this), does Nordic have such command in DFU service? or I need to defined a custom command myself?

(2) When the DFU target receive the DFU command, it will do sd_power_gpregret_set(0, BOOTLOADER_DFU_START),  disconnect all the connections and then reset, go into DFU mode after reboot, right?

But how could host know about whether the DFU target was ready in DFU mode or not? Do I need to reponse a specified command to tell host that it was ready to DFU after it reboot? Do I need to clear the SD_POWER_GPREGRET_SET after DFU done?

Best regards,

Tengfei.

Parents
  • +1

    Hi,

    1. The bootloader start address is stored in the UICR registers in flash (in UICR.NRFFW[0]), also known as NRF_UICR_BOOTLOADER_START_ADDR or .uicr_bootloader_start_address. This is what is used for deciding where application data is stored. In SDK 14.2, the BOOTLOADER_START_ADDR define is used throughout the code, and it is fetched from the flash settings for the project. Please note however that you cannot do DFU from a bootloader of one size to a bootloader of larger size, as then application data location and bank size calculations might fail.

    2. For bootloader update, the new bootloader is first downloaded to a separate location. Then the MBR is invoked for performing the copy operation into the final location. This copy operation is safe. The MBR starts by writing to the MBR parameter storage page in flash what copy operation is to be performed. If it gets aborted (for instance by power failure) it will retry on the next boot.

    If the bootloader is successfully updated, but the new bootloader has bugs that prevents it from doing DFU, then you have no choice other than programming the nRF directly. Therefore you should only update to a well tested bootloader such as the ones we provide with the SDK. If you modify it you should be extra careful with testing that it works as intended. This is also a good reason to use Secure DFU, which uses signing to prevent others from making a fake update that bricks the device.

    3. That should work, yes.

    Regards,
    Terje

Reply
  • +1

    Hi,

    1. The bootloader start address is stored in the UICR registers in flash (in UICR.NRFFW[0]), also known as NRF_UICR_BOOTLOADER_START_ADDR or .uicr_bootloader_start_address. This is what is used for deciding where application data is stored. In SDK 14.2, the BOOTLOADER_START_ADDR define is used throughout the code, and it is fetched from the flash settings for the project. Please note however that you cannot do DFU from a bootloader of one size to a bootloader of larger size, as then application data location and bank size calculations might fail.

    2. For bootloader update, the new bootloader is first downloaded to a separate location. Then the MBR is invoked for performing the copy operation into the final location. This copy operation is safe. The MBR starts by writing to the MBR parameter storage page in flash what copy operation is to be performed. If it gets aborted (for instance by power failure) it will retry on the next boot.

    If the bootloader is successfully updated, but the new bootloader has bugs that prevents it from doing DFU, then you have no choice other than programming the nRF directly. Therefore you should only update to a well tested bootloader such as the ones we provide with the SDK. If you modify it you should be extra careful with testing that it works as intended. This is also a good reason to use Secure DFU, which uses signing to prevent others from making a fake update that bricks the device.

    3. That should work, yes.

    Regards,
    Terje

Children
  • 0 in reply to tesc

    Thank you very much! I've fully understood it.

  • 0 in reply to Liu Tengfei

    Hello, Liu Tengfei. May I ask you a question ?Have you successfully completed the work of serial dfu? I’m using nrf52832  and SDK 14.2.0. In my project ,there are two dsp,one is nrf52832 and the other is ntk658, they connect via uart with each other. ntk658 supports the sd-card function.What i want to do is using ntk658 read the ble update fw and then transfer to nrf52832 via uart. So i know i need use serial DFU bootloader.Actually,i have done it in my another project. But i used SDK 11.0.0.And the packet format is very clear as following picture shows, 

     But my question is what the packet format should i send to nrf52832 in SDK 14.2.0? How can i transfer the ble upgrade fw to nrf52832?

Related
Terms of service