nrf52840 S140 Central DFU Bluetooth Zephyr 2.0.0 nrf52840 peripheral

[DavidKaplan]

We have nrf52840 S140 BLE Central device that currently connects to TI based sensors. I have implemented code that can upgrade those TI sensors' firmware using the TI BLE protocol.

Now we are developing our own BLE peripheral sensors also based on the nrf52840 but now using the newly supported Zephyr 2.0.0. RF connect stuff. I can update the sensors using the Nordic Android program (unauthenticated for now) and now need to implement upgrading BLE DFU using our central device which connects to a cellular gateway.

I do not want to reinvent the wheel, writing existing code, like I had to do with the TI sensors.

Could you point me to code that allows a Central device to update a peripheral device BLE DFU?

If not where can I look to reinvent another wheel?

Thanks David

[Simon]

Have a look at the sample Bluetooth: Central SMP Client

Then use the SMP sever Sample on the Bluetooth Peripheral device

Currently it is only possible to send the echo command from the Central SMP Client, so you would have to implement the other commands yourself, like upload, list, test and so on.. 

Best regards,

Simon

[DavidKaplan]

Now I have gotten back to this issue with our custom sensor hardware to arrive next week.

I have used the Android nRF Toolbox app successfully to update an unsigned image whereas the Nordic DFU tool did not work.

I understand that the Android apps use the SMP protocol that ties in with the img_mgmt libraries.

Where can I find documentation on what the Android app does so I can reproduce it in c in my central device?

Without any documentation it will be very hard for me to reverse engineer the Java somehow.

I do not want to have to add more code in the sensor to handle a custom DFU if possible since it already exists and the Zephyr junk makes a giant image anyway.

I saw a post with my exact request,  but I understand that it is not a priority issue.

 BLE DFU, MCU to MCU (Zephyr), GATT DFU SMP Service Clinet 

I also saw a SoftDevice (not Zephyr) example post of what I need but uses the old DFU stuff I think and SoftDevice APIs

 Mesh DFU: Serial transfer of DFU archive 

I need much more information to implement upload,list & test SMP commands that evidently exist in my sensor using the SMP server.

Could it be that the Android app used some legacy DFU?

Thanks David

[Simon]

DavidKaplan said:

Where can I find documentation on what the Android app does so I can reproduce it in c in my central device?

I would recommend you to use the nRF Connect Device Manager app. It is made for just this purpose, perform DFU updates using the mcumgr protocol. Here is the source code https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager

Regarding documentation about this app, maybe take a look at the readme file: https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager#readme 

To answer your question, you can find the list of commands you need to run in the smp_svr documentation. To summarize, these commands needs to run in this order from the central SMP Client sample:

• Upload the image
  • https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#upload-the-signed-image 
• List the image to get the hash of the newly uploaded image
  • https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#list-the-images
• Set the status to "test" for the newly uploaded image
  • You need to use the hash you got from running the last command 
  • https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#test-the-image
• Reset the chip
  • When resetting, mcuboot will now see that there is an image in the secondary slot, with status set to "test", it will then swap the current running application residing in the primary slot with the new image. Next, mcuboot will boot into the primary slot (where the newly uploaded image now is located)
  • https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#reset-remotely 
• Confirm the image
  • Since the status of the newly uploaded image is "test", if you reset the chip again, mcuboot will swap them back. So set the status to "confirm" to avoid this from happening
  • You can also run this command from within the application itself, but it is important that you run this command after you know the newly uploaded image runs without issues, so you don't brick your device 
  • https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.1/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/README.html#confirm-new-image

This is basically the commands you need to run to perform a DFU update

You can try to make an attempt to merge these commands into the SMP Client sample, and let me know if you have issues, and I will try to assist. It is a little bit hectic now in support since a huge part of the support team are on summer vacation, but I can make an attempt on this if you would like after my vacation ends around the 15th of august.

However, you don't really need to use the mcumgr protocol to perform the update. See my explanation in this ticket:  RE: Update code via UART instead of FOTA nRF9160  

If it's too difficuilt to implement the mcumgr command you can just use the approach I explained in this ticket

In this ticket UART is used. However, this is just the transfer medium, so what I say is also valid for you.

Best regards,

Simon

[DavidKaplan]

Our hardware is supposed to arrive by the end of the day.

Our Gateway, uses a host microcontroller with a cellular modem, connected by a uart serial channel to a MS88SF2 module with the nRF52840 chip as a Central device.
The nRF52840 has no external storage.
When updating TI sensors, the image information is first sent, which is used to start the TI OAD.
Then, I stream the new image bytes to a 64K ram buffer on the nRF52840 while it writes TI BLE OAD packets.
I must keep the ram buffer filled or the TI OAD process will fail with a timeout.

It does look very daunting to reconstruct the Kotlin code using the SMP protocol in my Central code.
I am still exploring my different options but I was thinking of trying something based on the multi-NUS-master example.

Very roughly something like this:
1) The Central will receive an image update message with the new image information (size,crc,etc) and which Peripherals to update from its host.
2) The Central will connect to all of its peripherals that need the image update.
Every message below will be broadcast to all connected periperals.
3) The Central will send a message to erase its slot#1 image
Is Slot#1 correct?
What API should I call?
4) The Central will send image block packets to fill up a 64K ram buffer.
5) The Central will send a message to flash the 64K to Slot#1 at the specified offset.
What API should I call?
6) The Central will continue with steps 4) & 5) until the whole image has been written.
7) The Central will send a message to get the image's hash.
What API should I call?
8) The Central will send a message to "test" the image
What API should I call?
9) The Central will send a message to reset the peripheral.
What API should I call?
10) Upon reconnection, the Central will send a message to "confirm" the image.

If the nRF Toolbox app is able to upgrade the peripheral, do I need any new prog.confg defines for the suggested API?

Another quick question that is related.
If I design the project with a mode that leaves the Peripherals always connected,
I understand that I may be able to get an even lower Peripheral current drain.
If a Peripheral is at the edge of the BLE signal range or there is a lot of interference ,
will I end up wasting a lot for current?

Thanks David

[Simon]

Hello and sorry for the delay. I've been gone on vacation the last two weeks.

Could you update me on the current state of this ticket? Then I will help you accordingly.

Best regards,

Simon