UART DFU of a nRF9160 in recovery mode via nRF5340.

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Hieu — Sun, 22 Dec 2024 15:16:37 GMT

Hi Colin,

[quote user="ColinC"]

I tweaked the code I sent you and managed to get some image transfer over UART going with the Interrupt driven transport layer.

The tweak consists in removing the CONFIG_UART_2_NRF_ASYNC, CONFIG_UART_2_NRF_ASYNC_TIMER and CONFIG_NRFX_TIMER2 statements and

[/quote]

To use interrupt driven mode, you should only need to disable CONFIG_UART_ASYNC_API and enable CONFIG_UART_INTERRUPT_DRIVEN. Were there some issues doing just this?

[quote user="ColinC"]Unfortunately, the SMP server which should consume the image always sends answers with the "off" field set to -1. I believe it indicates that no byte of the image was written to flash, is that correct? [/quote]

I am not sure what kind of response you are talking about here. What is your response frame?

The response is defined here: https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/zephyr/services/device_mgmt/smp_protocol.html#minimal_response

[quote user="ColinC"]Switching to the ASYNC transport layer, the transport layer of the SMP client times out although an answer is coming from the SMP server. I recorded the UART traffic with Saleae's logic analyser: here are the traces: [/quote]

This goes back to the setup of the UART API types. To use async, you should only need to enable CONFIG_UART_ASYNC_API and disable CONFIG_UART_INTERRUPT_DRIVEN. Could you please try this and see if the communication works properly?

Also, am I right to understand that we are only talking about the nRF5340/SMP Client UART configurations, and the nRF9160's UART configuration is left as default?

And can I take it you are not using LPUART? It's the default interface between the nRF52840 and nRF9160 in the nRF9160 DK Cellular + BLE setup.

Please be informed that I will be out of office for a few weeks. If you have any follow-up questions, please just reply and one of our engineers will continue to support you.

Best regards,

Hieu

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Thu, 19 Dec 2024 09:39:44 GMT

Hi Hieu,

Tanks for the support! Yeah I made progress, I tweaked the code I sent you and managed to get some image transfer over UART going with the Interrupt driven transport layer.

The tweak consists in removing the CONFIG_UART_2_NRF_ASYNC, CONFIG_UART_2_NRF_ASYNC_TIMER and CONFIG_NRFX_TIMER2 statements and

Unfortunately, the SMP server which should consume the image always sends answers with the "off" field set to -1. I believe it indicates that no byte of the image was written to flash, is that correct?

Switching to the ASYNC transport layer, the transport layer of the SMP client times out although an answer is coming from the SMP server. I recorded the UART traffic with Saleae's logic analyser: here are the traces:

devzone.nordicsemi.com/.../Interrupt_5F00_driven_5F00_no_5F00_data_5F00_consumed.sal devzone.nordicsemi.com/.../Async_5F00_timeouts.sal

The files can be opened with Saleae's "Logic" tool. Maybe you can look into it and understand better than me, why timeouts happen, when I use the async SMP transport layer and why no bytes are consumed with the interrupt driven SMP transport layer.

Thank you for the support!

Kind regards

Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Hieu — Wed, 18 Dec 2024 16:06:50 GMT

Hi Colin,

As you might have been notified by email, since a few days ago, I have been assigned to continue supporting you with this issue while Charlie is unavailable.

To give you an update, I am a little familiar with DFU solutions, but entirely new to using SMP Client, and am still trying to figure things out myself.

I will continue looking into it and get you a reply probably this Friday or Saturday.

By the way, have you made any progress since?

Hieu

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Wed, 04 Dec 2024 13:48:58 GMT

Hi Charlie,

Tanks for looking in the code, I would indeed be glad if someone could take over while you are away 🙂.

I also started studying the lwm2m sample, got the FW running on the nRF9160 and the nrf52840. But I had to go back to SDK version 2.5.0 since the sample description didn't match the folder structure in v2.7.0 due to the build tool being sysbuild and the lack of child_image folder.

The sample FW seems to work but executing the fota.py script runs into a 403 error when trying to register the new resource for the app_update52.bin image. Is it possible that the behaviour of the coiote server has changed and does no longer match the fota.py script or is the problem on my side?

Regarding the lwm2m_client sample: I am interested in the case "LwM2M Firmware Update for external MCU" could you tell me how the SMP transfer is triggerd and how the data flow is? I tried to find the API calls to mcu_mgr but to no avail.

Thanks a lot for the support!

Cheers

Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Tue, 03 Dec 2024 19:41:28 GMT

Hi Colin,

I spent some time reviewing your codes today but, unfortunately, wasn’t able to make any progress.

I’ll be on leave until next Tuesday, but I’ll continue looking into it once I’m back. In the meantime, if there’s capacity within our team, someone else may be able to take a look.

Thank you for your patience, and feel free to reach out if there are any updates or additional information to share.

Best regards,
Charlie

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Mon, 02 Dec 2024 12:15:53 GMT

Hi Charlie,

Thanks for the reply, I'll give it a go.

In the meantime I have worked on some code I can share with you. It shows exactly how I intend to Pass the new nRF9160 image around, furtther details are explained in the README file. Please look if you manage to get it going on your DKs (I am available for further information). Maybe you can also give me feedback on the concept I present in the readme regarding the upating of the nRF9160.

devzone.nordicsemi.com/.../8371.Firmware.zip

Kind Regards

Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Mon, 02 Dec 2024 11:56:38 GMT

Hi Colin,

It seems that your nRF5340 SMP client configuration does not fully reference the nrf\samples\cellular\lwm2m_client\overlay-mcumgr_client.conf file. To ensure the setup is correct, I recommend trying to use the original nrf\samples\cellular\lwm2m_client as an SMP client on the nRF9160 to perform DFU for another nRF9160 configured as an SMP server.

This should serve as a solid preliminary study before attempting to implement and run an SMP client on the nRF5340.

Best regards,

Charlie

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Sat, 30 Nov 2024 14:12:19 GMT

Hi Charlie,

Tanks for the reply, I am working on a small example with a nRF5340 DK and a nRF9160 DK, based on the serial recovery DFU sample for the 9160 and the BLE FOTA sample for the 5340 (in the Academy Lesson 8 exercises 1 and 3) I will share them as soon as I have something.

In the FW I managed to get rid of the Attribution unit violation. The issue was that no transport layer was assigned and thus the smp_client_object_init() could not be called properly.

Now I am able to call img_mgmt_client_upload(). This indeed results in traffic on the TX uart line as the first few transport frames get sent out. The nRF9160 responds with a 35 byte SMP packet after 90 ms. Which looks as follows:

First 64 bytes of the image sent as SMP frames (nRF5340 -> nRF9160):

06 09 41 47 67 43 41 41 42 65 41 41 45 41 41 62 
39 6C 61 57 31 68 5A 32 55 41 5A 47 52 68 64 47 
46 59 51 44 32 34 38 35 59 41 41 41 41 41 41 41 
49 41 41 44 6A 56 41 67 41 41 41 41 41 41 41 51 
41 41 41 41 41 41 41 41 41 41 41 41 41 41 2F 2F 
2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 2F 
2F 2F 2F 2F 2F 2F 2F 2F 39 6A 62 32 5A 6D 0A 04 
14 41 47 4E 73 5A 57 34 61 41 41 4C 58 7A 2F 39 
4C 58 67 3D 3D 0A

Response fom (nRF9160-> nRF5340):

06 09 41 42 59 44 41 41 41 4D 41 41 45 41 41 62 
39 69 63 6D 4D 41 59 32 39 6D 5A 68 6A 51 2F 37 
47 53 0A

Unfortunately I am unable to parse it to verify for error codes. This could confirm whether or not the nRF9160 accepts the incoming traffic.

The issue is that the nRF5340 does not react to the incoming response. No uart handlers get triggered despite uart_rx_enable() having been called, a handler registered with uart_callback_set() and the Following interrupts being enabled

For the MCUMGR configuration I use the following kconfig settings :

#Enable DFU SMP Target for nRF9160 DFU  
CONFIG_DFU_TARGET=y
CONFIG_MCUMGR_GRP_OS_CLIENT=y
CONFIG_DFU_TARGET_SMP=y
CONFIG_CONSOLE=y
CONFIG_UART_MCUMGR=y
CONFIG_MCUMGR_TRANSPORT_UART=y
CONFIG_MCUMGR_TRANSPORT_UART_ASYNC=y
CONFIG_SHELL=y
CONFIG_BASE64=y

# Enable SMP Server
CONFIG_MCUMGR=y
CONFIG_MCUMGR_GRP_IMG=y
# CONFIG_MCUMGR dependencies
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y
# CONFIG_MCUMGR_GRP_IMG dependencies
CONFIG_SMP_CLIENT=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR_GRP_IMG_CLIENT=y
# CONFIG_IMG_MANAGER dependencies
CONFIG_STREAM_FLASH=y
CONFIG_MCUMGR_MGMT_NOTIFICATION_HOOKS=y
CONFIG_MCUMGR_SMP_COMMAND_STATUS_HOOKS=y
CONFIG_MCUMGR_GRP_IMG_UPLOAD_CHECK_HOOK=y
CONFIG_MCUMGR_GRP_IMG_STATUS_HOOKS=y

Do you see anything wrong about my uart config or why the response gets ignored by the nRF5340?

Thanks a lot for your support

Kind regards

Colin Cina

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Thu, 28 Nov 2024 12:56:56 GMT

Hi Colin,

In addition to the usage demonstrated in v2.8.0\nrf\tests\subsys\net\lib\mcumgr_smp_client, I found the following sample and guidance that showcase the mcumgr client with the img_mgmt_client API:

https://docs.nordicsemi.com/bundle/ncs-2.8.0/page/nrf/samples/cellular/lwm2m_client/sample_description.html#mcumgr_client_for_external_fota

Exercise 1 - DFU over UART - Nordic Developer Academy

I recommend closely comparing the usage of the img_mgmt_client API in these samples to ensure your implementation aligns with the demonstrated best practices.

If the issue persists, I encourage you to share a minimal version of your mcumgr client implementation, excluding any confidential code. This will help us analyze and troubleshoot the problem more effectively.

Best regards,

Charlie

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Tue, 26 Nov 2024 16:48:43 GMT

Hi, I am back with some more insights and questions on the usage of the img_mgmt_client. The API usage seems to be restricted to the test code.

The project I am working on is confidential so I can't share the whole code. Here is a short snippet that shows how I use the img_mgmt_client API :

struct mcumgr_image_upload res_buf; 
struct img_mgmt_client img_mgr_cli;
struct smp_client_object smp_client;
struct mcumgr_image_data img_data[1];

#define READ_SIZE 124 

//Initialize the smp_client and the img_mgmt_client
smp_client_object_init(&smp_client, SMP_SERIAL_TRANSPORT);
img_mgmt_client_init(&img_mgr_cli, &smp_client, 1, img_data);

//Initialise the image upload
err = img_mgmt_client_upload_init(&img_mgr_cli, image_size, 0, NULL);
if(err != 0){
    LOG_ERR("Failed to initialise the image upload");
}

//Upload one chunk to the nRF9160
err = img_mgmt_client_upload(&img_mgr_cli, image_data, READ_SIZE, &res_buf);

The execution of

img_mgmt_client_upload() fails due to an Attribution unit violation, the call stack is as follows:

sys_dlist_remove(sys_dnode_t * node) (ncs\v2.7.0\zephyr\include\zephyr\sys\dlist.h:506) 

sys_dlist_get(sys_dlist_t * list) (ncs\v2.7.0\zephyr\include\zephyr\sys\dlist.h:530) 

handle_poll_events(uint32_t state, struct k_queue * queue) (ncs\v2.7.0\zephyr\kernel\queue.c:90) 

queue_insert(struct k_queue * queue, void * prev, void * data, _Bool alloc, _Bool is_append) (ncs\v2.7.0\zephyr\kernel\queue.c:170) 

net_buf_put(struct k_fifo * fifo, struct net_buf * buf) (ncs\v2.7.0\zephyr\subsys\net\buf.c:450) 

smp_client_send_cmd(struct smp_client_object * smp_client, struct net_buf * nb, smp_client_res_fn cb, void * user_data, int timeout_in_sec) (ncs\v2.7.0\zephyr\subsys\mgmt\mcumgr\smp_client\src\client.c:322) 

img_mgmt_client_upload(struct img_mgmt_client * client, const uint8_t * data, size_t length, struct mcumgr_image_upload * res_buf) (ncs\v2.7.0\zephyr\subsys\mgmt\mcumgr\grp\img_mgmt_client\src\img_mgmt_client.c:420) 

perform_nrf9160_dfu(struct k_work * work) (Application Level Function, Top of callstack)

It seems that the FIFO element in the SMP_client struct makes an illegal access. But I don't understand why, as I have initialized the SMP_client.

Right now I am still unsure if using the img_mgmt_client API directly from Application level code the correct way is or what I am missing.

Based on this update, do you have more inputs that could help me advance with the DFU implementation?

Thank you for the support

Cheers, Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Wed, 30 Oct 2024 10:00:24 GMT

Of course, thank you for sharing your findings in advance, other developers will definitely benefit from your contribution.

I will keep this ticket open.

Best regards,

Charlie

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Wed, 30 Oct 2024 09:45:23 GMT

Hi Charlie,

Alright, I will give it a try. Could we leave this question open so that I can give an update if this is actually the way to go about it? It might be of interest of other users.

Cheers,

Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Wed, 30 Oct 2024 09:42:56 GMT

Hi Colin,

I never tried myself with this img_mgmt_client API. I would sugget you just give a try to verfiy your concern.

You can learn about the API usage by searching the function name in NCS code base direclty. I found some testing codes that shows the usage of img_mgmt_client_upload.

Since smp is a subsystem maintained in Zephyr, you can try to reach developers at https://github.com/zephyrproject-rtos/zephyr/issues if there you encounter any issue during your exploration.

Best regards,

Charlie

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

ColinC — Tue, 29 Oct 2024 14:09:30 GMT

Hi Charlie,

Thank you for the answer, interesting stuff! I'll study the Advanced Firmware Update for external MCU article.

How I understand it, I have to use the img_mgmt_client API from my Application on the nRF5340.

First calling img_mgmt_client_init and passing an smp_client_object struct which selects the uart transport layer.

Assuming my statement above is correct:

If I have the image of the nRF9160 stored in flash, can I simply read the image chunkwise from flash passing it to call img_mgmt_client_upload()? Does the size of the data chunks matter or does the img_mgmt_client and the underlying transport layer handle it?

If my assumption is wrong, could you point me to the right API to use from the nRF5340 application to send chunks of the nRF9160 image to the nRF9160 via SMP using the uart transport layer?

Many thanks for the support

Cheers

Colin

RE: UART DFU of a nRF9160 in recovery mode via nRF5340.

Charlie — Tue, 29 Oct 2024 12:45:43 GMT

Hi Colin,

Thanks for checking with us about this concept.

This concept is totocally possible and you basiclly have everything you need on the current NCS/Zephyr, Even the opposite or bidirection is possible, nRF9160 downloads firmware through LTE and do firmware update for another MCU like Evaluating LwM2M Advanced Firmware Update for external MCU did. You need to add smp client/server to your MCUs accordingly.

I know some companies implemented this solution based on this concept. See the references mentioned in this discussion provided by my colleague (3) Assistance Needed for BLE DFU of Device B Using Device A as Central - Nordic Q&A - Nordic DevZone - Nordic DevZone.

Best regards,

Charlie