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

Nordic DFU library/BLE service to download the firmware image to an external uC through nrf52832

Hello everyone!

I'm working on a project where there are 2 microcontrollers: the Nordic nrf52832 and a 3rd-party uC (can't disclose it). A protocol to transfer the firmware image to a bootloader application in the target uC is working already. We'd like to use Nordic's DFU library to transfer the firmware from a mobile app (could be nrfConnect if possible).

We have implemented and tested a firmware solution that works with the buttonless DFU for upgrading its own firmware, but that was pretty much straightforward after studying the Nordic's examples provided with the SDK.

Is there an example to take a look at with some similar solution?

Is there any guideline to use the DFU library for a custom solution like this one?

This is my system configuration:

Segger Embedded Studio, Nordic SDK 14.2, S132 SoftDevice v5

Thanks in advance!

Parents
  • Hi Jose, 

    Please correct me if I'm wrong. What you want is to use nRFConnect/nRFToolbox app on the phone to transfer the image to the NRF52 and the NRF52 DFU update the image on the 3rd party uC  ?

    We currently don't have any example that can do exactly that. But if you already have the code to transfer an image from the nRF52 to the 3rd party uC. I don't see much problem combining the Nordic DFU library with what you have already implemented. 

    What you need to is to have a check in the the bootloader on the nRF52. If it's the image for the external uC, you will store the image in a dedicated place in flash (can be the same swap space as on normal DFU) and then you skip the activation process where we replace the old image with the new image. Instead you trigger your own DFU process to send image from nRF52 to the external uC. 

  • Hi Hung Bui,

    Thanks for your reply. What you described is what I want to implement. What is not clear for me (maybe you could provide some clues) is know the nRFConnect/nRFToolbox apps work when transferring the firmware image to the NRF52 via Bluetooth.

    I've tried to understand the DFU library but is giving me a hard time. I guess is not meant to be modified or customized.

    In our current system, we have the Nordic bootloader -triggered by the buttonless DFU service- for upgrading the main application firmware. We have done the process of updating the firmware with the nRFConnect App several times. Basically what we load on the App is a zip file generated by the nrfutil tool. We don't want to go that far, we'd be happy just loading the 3rd party uC hex -file on the App, but (the big but) what the DFU service transfers are not hex-file records, from my analysis, is actually binary data to be programmed into the flash with no further processing or decoding. Please correct me, if I'm wrong. I tried to get the source code of the nrfConnect App but is not public.

    I've read that there is a legacy mode where you can load a hex-file to the App. Does that work?

    My question: Do the Apps (nRFConnect/nRFToolbox) decode the hex file and send binary data to the bootloader? Does the app emulate the NRF52 memory and then send blocks of data? 

    Thanks a lot for your support!

  • It doesn't really matter which file you provide to the nRFConnect App. The actual image transfer over the air is binary image not the hex. If you transfer hex, the bootloader will have a hard time converting hex to binary which is unnecessary.

    Same when you do normal JTAG/SWD programming, or when you send the image from nRF52 to your uC, I assume you transfer the binary , not the hex ? 

    To achieve what you want to do, I don't think there is an easy way without understand fully how the bootloader work and where you should modify the code. In addition, you would need to modify the package format to add an extra information that the image is for the nRF52 or for the extra uC. 

    In our bootloader, the place where we swap the application with the new image is in app_activate(). You would need to disable this and start your transfer instead. 

Reply
  • It doesn't really matter which file you provide to the nRFConnect App. The actual image transfer over the air is binary image not the hex. If you transfer hex, the bootloader will have a hard time converting hex to binary which is unnecessary.

    Same when you do normal JTAG/SWD programming, or when you send the image from nRF52 to your uC, I assume you transfer the binary , not the hex ? 

    To achieve what you want to do, I don't think there is an easy way without understand fully how the bootloader work and where you should modify the code. In addition, you would need to modify the package format to add an extra information that the image is for the nRF52 or for the extra uC. 

    In our bootloader, the place where we swap the application with the new image is in app_activate(). You would need to disable this and start your transfer instead. 

Children
No Data
Related