nRF5340 - UART programming option

RE: nRF5340 - UART programming option

Gabriele — Fri, 25 Sep 2020 15:10:33 GMT

Hello Hung

I've solved on this thread dfu-over-serial-mission-impossible

Thank you for support

RE: nRF5340 - UART programming option

Hung Bui — Fri, 25 Sep 2020 15:06:08 GMT

Hi Gabriele,

I'm sorry that I haven't got time to look into this yet.
I would suggest you to have a look at the source code of the Thingy 91.

According to this guide:
https://devzone.nordicsemi.com/nordic/cellular-iot-guides/b/getting-started-cellular/posts/thingy91_2d00_fw_2d00_update_2d00_mcuboot

It will trigger the image swap/confirm after a reset after the DFU. I will try to work on this issue next week.

RE: nRF5340 - UART programming option

Gabriele — Tue, 22 Sep 2020 09:48:30 GMT

Hello Hung. Any news on this ?
I've seen a couple of API functions I guess could be of help to call from within application

int boot_set_pending(int permanent);
int boot_set_confirmed(void);

Not sure this makes sense.
They are implemented in
ncs/bootloader/mcuboot/boot/bootutil/src/bootutil_misc.c
However it is not clear how to link them to the application.
Adding
#include <bootutil/bootutil.h>
doesn't suffice.

RE: nRF5340 - UART programming option

Gabriele — Tue, 15 Sep 2020 09:33:54 GMT

Ok, thank you!

RE: nRF5340 - UART programming option

Hung Bui — Tue, 15 Sep 2020 08:52:30 GMT

Hi Gabriele,

1.I'm sorry I forgot to check the warnings. You need to add

#include "os_mgmt/os_mgmt.h"

#include "img_mgmt/img_mgmt.h"

to you main.c

A good reference for using the bootloader is to have a look at the smpsvr sample located at \zephyr\samples\subsys\mgmt\mcumgr\smp_svr

2. Yes you use app_update.bin. If you have a look at the link on FOTA I pointed to earlier you can find that suggestion.
You can sign the image yourself but I haven't been very successfully managed to do so. The documentation is here: https://docs.zephyrproject.org/latest/samples/subsys/mgmt/mcumgr/smp_svr/README.html

If you want to switch between smpsvr and your application, I think it's the mcumgr handle it. I haven't looked into how you do it automatically yet. Will get back when I find the way.

RE: nRF5340 - UART programming option

Gabriele — Mon, 14 Sep 2020 14:29:45 GMT

Dear Huang

Thank you for guiding me with lot of patience.

1) At build time I get a couple of warnings
warning: implicit declaration of function 'os_mgmt_register_group'
warning: implicit declaration of function 'img_mgmt_register_group'

Is there something I can do about it, or just ignore and go on ?

2) Are you sure app_update.bin us the correct binary image ?
Indeed we have a variety of choices:

- app_update.bin
- app_signed.hex
- app_test_update.hex
- app_moved_test_update.hex

My goal is to control from MyApp whether to stay in MyApp or reboot in "SMP Server mode" to upload a new version of MyApp

RE: nRF5340 - UART programming option

Hung Bui — Mon, 14 Sep 2020 12:16:52 GMT

Hi Gabriele,
You would need to integrate smpsvr into your application.
It's pretty simple. You can just follow the instruction here.
The instruction is for BLE , to do UART DFU you use CONFIG_MCUMGR_SMP_UART = y instead of CONFIG_MCUMGR_SMP_BT.
In your main.c you need to call

os_mgmt_register_group();
img_mgmt_register_group();

In the example, I have prepared the .bin files that you can use to update. Note that after you do :

mcumgr -t 20 --conntype serial --connstring=COM37 image upload app_update_new.bin

You still need to confirm the image "image confirm <img_sha>" and then do a reset. I haven't looked into how you can confirm the image and reset automatically yet.

devzone.nordicsemi.com/.../peripheral_5F00_lbs_5F00_dfu_5F00_uart.zip

RE: nRF5340 - UART programming option

Gabriele — Fri, 11 Sep 2020 15:44:38 GMT

Hi,

The swap mechanism went well!
After a "image confirm" the new image (My App) is the active one, persistently.

But what ? I cannot upload a brand new image.
How to restore the DFU functionality ?

RE: nRF5340 - UART programming option

Hung Bui — Fri, 11 Sep 2020 15:33:53 GMT

Hi,

After you have flashed the smp_svr you can use the mcumgr to DFU your image .

After you have your image list with 2 images, you need to either test or confirm the image and trigger a reset for your app to run.
Call `Image test <image sha>` or `image confirm <image sha>` and then do a reset. Your application should run after that.

RE: nRF5340 - UART programming option

Gabriele — Fri, 11 Sep 2020 12:30:14 GMT

Thank you for your reply.

I think the problem was due to flashing non signed binary for smp_srv.

Now I'm able to

a) Build and flash mcuboot in bootloadr_partition (using JLink)
b) Build and flash smp_svr in slot0_partition (using JLink)
c) Build and flash MyApp in slot1_partition (using DFU)

This is the resulting mcumgr image list

Images:
image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 6645ebafd4a33787a52b5f76c18f9b66038a25b3413238e22d2432e6bba47677
image=0 slot=1
    version: 1.3.0
    bootable: true
    flags:
    hash: 17563829483019977c328c7c89114dcb2f872c65b9b5c8d663011e617b9915ad
Split status: N/A (0)

Now I see a problem.

On system restart I get out of UART

*** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***
[00:00:00.003,051] <inf> mcuboot: Starting bootloader
[00:00:00.009,246] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.019,348] <inf> mcuboot: Boot source: none
[00:00:00.024,810] <inf> mcuboot: Swap type: none
[00:00:00.138,214] <inf> mcuboot: Bootloader chainload address offset: 0x10000
[00:00:00.146,026] <inf> mcuboot: Jumping to the first image slot
*** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***
[00:00:00.004,425] <inf> smp_sample: build time: Sep 11 2020 13:29:22

The smp_srv is running, not MyApp !

How to switch from smp_srv to MyApp, and viceversa ?

Thank you

RE: nRF5340 - UART programming option

Hung Bui — Fri, 11 Sep 2020 09:27:44 GMT

Hi Gabriele,

I'm sorry that it's been a long time and you still having issue with FOTA on nRF53.

We now have better documentation for nRF53 including FOTA instruction.

Please have a look here:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_nrf5340.html#fota-upgrades

The instruction is for FOTA using BLE. And I think you should test first using this transport. Just to make sure smpsvr is working fine. After that you can change CONFIG_MCUMGR_SMP_BT to CONFIG_MCUMGR_SMP_UART to support UART (and add CONFIG_SERIAL=y)

RE: nRF5340 - UART programming option

Gabriele — Thu, 10 Sep 2020 14:10:53 GMT

Hi Hung
I'm trying to follow your initial recipe

a) Build and flash mcuboot
$ cd <ncs>/bootloader/mcuboot/boot/zephyr
$ west build -b qi2m_nrf5340_cpuapp --build-dir buildout
$ nrfjprog -f nrf53 --program buildout/zephyr/zephyr.hex

I check out reading flash. One image found at
0x00000000 - 0x0000891f (35104 B)

b) Build and flash smp_svr
$ cd <ncs>/zephyr/samples/subsys/mgmt/mcumgr/smp_svr
$ vim prj.conf
Add these lines
CONFIG_MCUMGR_SMP_UART=y
CONFIG_NET_BUF_USER_DATA_SIZE=7
$ west build -b qi2m_nrf5340_cpuapp --build-dir buildout
$ nrfjprog -f nrf53 --program buildout/zephyr/zephyr.hex

I check out reading flash. Two images found at
0x00000000 - 0x0000891f (35104 B)
0x00010200 - 0x0001a62b (42028 B)

On board restart I get out of UART

*** Booting Zephyr OS build v2.3.0-rc1-ncs1 ***
[00:00:00.003,051] <inf> mcuboot: Starting bootloader
[00:00:00.009,063] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.019,165] <inf> mcuboot: Boot source: none
[00:00:00.024,566] <wrn> mcuboot: Failed reading image headers; Image=0
[00:00:00.032,012] <err> mcuboot: Unable to find bootable image

Issuing from host the test command

$ mcumgr -t 20 --conntype serial --connstring='/dev/ttyUSB0,baud=115200' image list

I get "Error: NMP timeout"

What a hell to do ?

RE: nRF5340 - UART programming option

Gabriele — Wed, 09 Sep 2020 15:51:54 GMT

Solved with
$ sudo pip3 install cbor

RE: nRF5340 - UART programming option

Gabriele — Wed, 09 Sep 2020 14:39:38 GMT

Hi Hung

Let me sum up the state of art as follow-up to this thread.

I've a nRF5340 custom board and a working Zephyr application I can build (under NCS v1.2.0), flash (using SWD), and run.
The UART works fine, either as console and generic user data.
Now, I want to perform DFU through the UART.
I need to include MCUBoot with MCUmgr with SMP server and Uart transport.

Here is what I've done

1. Add Uart support for mcumgr into board file <ncs>/zephyr/boards/arm/qi2m_nrf5340/qi2m_nrf5340_cpuapp_common.dts
chosen {
...
zephyr,uart-mcumgr = &uart0;
};

2. Change prj.conf of my application by adding
CONFIG_MCUMGR=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_NET_BUF=y
CONFIG_MCUMGR_SMP_UART=y

3. Rebuilding the application with
$ west build -b qi2m-nrf5340_cpuapp --build-dir buildout

I get the error

..
FAILED: zephyr/autogen/pubkey.c
ModuleNotFoundError: No module named 'cbor'

Is there anything missed ?
Does it help to move to NCS 1.3.0 ?

Thanks

RE: nRF5340 - UART programming option

Hung Bui — Tue, 03 Mar 2020 09:46:04 GMT

I don't think Go is needed for the UART dfu application.

However, DFU update is a quite complex application. I would suggest you to get started with testing normal UART application. You will need to have normal SWD programming (not UART DFU) for the development, make sure you have the SWD accessible and has the programmer (can be a nRF53 DK).

RE: nRF5340 - UART programming option

Gabriele — Mon, 02 Mar 2020 18:12:31 GMT

Hi Hung,
Thank you, this is a clean step-by-step recipe. I'm sorry I cannot test this in real time. These days much of my effort is on the PCB design. Consider that the DFU must get started from a Windows host, because the product is linked to a Windows PC where the user application runs. Thus, as for the first step, I think I have to install Go for Windows, right ?

RE: nRF5340 - UART programming option

Hung Bui — Mon, 02 Mar 2020 13:06:44 GMT

Hi Gabriele,

I haven't tried it on the nRF53 but, on the nRF91 what we did was:

- Add uart support for mcumgr into boards/arm/nrf9160_pca10090/nrf9160_pca10090_common.dts

https://github.com/osaether/zephyr/commit/fbd3daec22eacd7d2d3b1794bb01d9a263d23868

- Change prj.conf for nRF91 UART transport for smp_svr:

https://github.com/osaether/zephyr/commit/ee8e73de279c1cde0cfbe85392c047349f254fc7

- Then build and flash mcuboot

- Build and flash smp_svr

- Intall MCUMgr command line tool: https://github.com/apache/mynewt-mcumgr#command-line-tool

Use this to list the images in flash, just to test if you can communicate with smp_svr via UART

sudo mcumgr -t 60 --conntype serial --connstring='dev=/dev/ttyACM0,baud=115200' image list

- Test with a helloworld example:

cd ~/ncs/zephyr/samples/hello_world
echo "# Enable mcumgr.\nCONFIG_MCUMGR=y" >prj.conf
echo "# Ensure an MCUboot-compatible binary is generated.\nCONFIG_BOOTLOADER_MCUBOOT=y" >>prj.conf
echo "# Enable NET BUF\nCONFIG_NET_BUF=y" >>prj.conf
mkdir build
cd build
cmake -GNinja -DBOARD=nrf9160_pca10090 ..
ninja
# Sign the bin-file (the mcumgr cli does only work with bin-files):
~/ncs/mcuboot/scripts/imgtool.py sign --key ~/ncs/mcuboot/root-rsa-2048.pem --header-size 0x200 --align 8 --version 1.0 --slot-size 0x32000 zephyr/zephyr.bin signed.bin

-Perform DFU:

sudo mcumgr -t 60 --conntype serial --connstring='dev=/dev/ttyACM0,baud=115200' image upload signed.bin

- Run the image list above and it should show 2 slots.

RE: nRF5340 - UART programming option

Gabriele — Fri, 28 Feb 2020 15:18:19 GMT

Hi Hung,
at first glance this seems a very complicated path. It makes me wonder if it will work in the end.
I'll try to understand the documents you've linked

RE: nRF5340 - UART programming option

Hung Bui — Fri, 28 Feb 2020 14:57:45 GMT

Hi Gabriele,

I afraid the nrfutil tool that Igor pointed wouldn't work with the nRF53 (only support nRF52 and nRF5 SDK).

The nRF53 is not supported by our nRF5SDK (which the nrfutil supports)

For nRF53 you would need to use NRF Connect SDK. To do DFU with UART on nRF Connect SDK you would need to use mcumgr and smpsvr.
Please read about the smpsvr here.

And mcumgr here.

We have an example of using smpsvr and mcumgr via UART for the Thingy91 here. It's for the nRF9160 but it should be similar syntax for the nRF53.

RE: nRF5340 - UART programming option

Gabriele — Fri, 28 Feb 2020 12:50:15 GMT

Yes, thank you Igor. The document doesn't make any explicit reference to nRF5340, but I think it will work as well.

RE: nRF5340 - UART programming option

Igor — Fri, 28 Feb 2020 11:54:39 GMT

Do you mean this?
infocenter.nordicsemi.com/.../nrfutil_dfu_serial.html