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

[DavidKaplan]

I have been working on other things in this project and on other more urgent projects changes and fixes. 

Now I am back on this and still need to get this working somehow.

If you could just write the correct APIs in every step, I may be able to advance this. quicker.

One of my peripheral sensors stopped working when trying to measure its current.

It is not detected by the SDK. Is there any way to brick a nRF52840 or have I just damaged a pin?

Thanks David

[Simon]

DavidKaplan said:

3) The Central will send a message to erase its slot#1 image
Is Slot#1 correct?
What API should I call?

You should put the update into the secondary slot, so if you refer to the primary slot as slot#0 and the secondary slot as slot#1, then slot#1 is correct yes.

Regarding what API to call to erase the secondary slot, you can take a look at the function img_mgmt_upload()-->img_mgmt_impl_erase_image_data() (called in response to an mcumgr upload command), as you can see, it uses the function flash_area_erase() to erase the secondary slot.

DavidKaplan said:

5) The Central will send a message to flash the 64K to Slot#1 at the specified offset.
What API should I call?

Take a look at the same function img_mgmt_impl_erase_image_data(), as mentioned above. It will write to the secondary slot using img_mgmt_impl_write_image_data()-->flash_img_buffered_write()-->stream_flash_buffered_write()

If using fota_download+dfu_target_mcuboot (used by nRF91 to update appl.) the same function is used: dfu_target_write-->dfu_target_mcuboot_write()-->

stream_flash_buffered_write().

I guess it could work to just use flash_map.h-->flash_area_write() or flash.h-->flash_write, but as mentioned in the documentation, there are some advantages with using the Stream Flash API:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.0.0/zephyr/services/storage/stream/stream_flash.html#stream-flash 

"One typical use of a stream write operation is when receiving a new firmware image to be used in a DFU operation.

There are several reasons why one might want to use buffered writes instead of writing the data directly as it is made available. Some devices have hardware limitations which does not allow flash writes to be performed in parallel with other operations, such as radio RX and TX. Also, fewer write operations result in faster response times seen from the application."

DavidKaplan said:

7) The Central will send a message to get the image's hash.
What API should I call?

Check how it's done in the function \zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt\src\img_mgmt.c-->img_mgmt_read_info(), which will read the version and build hash from the specified image slot.

DavidKaplan said:

8) The Central will send a message to "test" the image
What API should I call?

Check out how how the image management library does it: \zephyr\subsys\mgmt\mcumgr\lib\cmd\img_mgmt\include\img_mgmt\img_mgmt.h-->img_mgmt_state_set_pending()-->img_mgmt_impl_write_pending()-->boot_request_upgrade_multi()

So you can set the image to a "test" (run once and then revert) state by running boot_request_upgrade_multi(int image_index, int permanent) with permanent=0, or confirm the image by setting permanent=1 (run image forever).

DavidKaplan said:

9) The Central will send a message to reset the peripheral.
What API should I call?

You can use \zephyr\lib\os\reboot.c-->sys_reboot() for this.

DavidKaplan said:

10) Upon reconnection, the Central will send a message to "confirm" the image.

You can do this by running boot_write_img_confirmed() from within the app itself, like it's done in the http_update sample: https://github.com/nrfconnect/sdk-nrf/blob/v2.0.2/samples/nrf9160/http_update/application_update/src/main.c#L60 

DavidKaplan said:

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

If you wan't to perform a DFU app from the phone using custom BLE commands and the APIs I suggested above, you can use the nRF Connect for Mobile app: https://www.nordicsemi.com/Products/Development-tools/nrf-connect-for-mobile 

If you want to perfom a DFU using mcumgr protocol, I suggest using the nRF Connect Device Manager app and follow the DFU guide.

DavidKaplan said:

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?

This is not my area of expertise. Could you open a new ticket and ask about it there. I think you will get better help then.

Best regards,

Simon