mcumgr communication times out with NMP when nRF5340 supports DFU.

[kudo]

Hell,

I wrote an application with DFU support added to nRF5340, and mcumgr communication on the Linux machine connected via UART times out.

environment

• Development PC :Windows10
• Development environment :Visual Studio Code
• SDK :nRF Connect SDK v2.3.0

procedure

1. Modify the hello world sample and enable the DFU function on nRF5340 according to the website below.
   1. https://devzone.nordicsemi.com/guides/nrf-connect-sdk-guides/b/software/posts/ncs-dfu#serial_dfu
2. Disable the mass storage function of nRF5340 using J-Link Commander's MSDDisable command.
3. Write the modified application to nRF5340 using VScode.
4. Connect Linux machine and nRF5340 with UART.
5. Communicate with the following command from the Linux machine.
6. Timeout occurred

mcumgr --conntypeserial --connstring "/dev/ttyLP3,baud=115200" image list
Error: NMP timeout

Since the uart signal is being sent, it seems that the problem is with the application written to the nRF5340.

Please tell me how to make uart DFU work with nRF5340.

[Håkon Alseth]

Hi,

 

Have you verified the serial DFU behavior on other systems than the linux system that you're currently running?

 

Kind regards,

Håkon

[kudo]

Hi Håkon,

I also tried it on a Windows 10 machine, but the symptoms remained the same.

[Håkon Alseth]

Here's a hello_world with dfu serial:

hello_world_serial_mcumgr.zip

Note that this lacks:

* support for external flash storage

* does not use mcuboot recovery

 

Can you try this?

 

Kind regards,

Håkon

[kudo]

Hi Håkon,

Thank you for providing the code.

I built and wrote the code you provided in VS Code and tried mcumgr's image list communication, but the problem remains and it still times out.

[Håkon Alseth]

Hi,

 

I used ncs v2.3.0 with the below sample, in combination with nRF5340-DK for testing.

image list:

$ mcumgr --conntype serial --connstring "/dev/ttyACM1,baud=115200" image list
Images:
 image=0 slot=0
    version: 0.0.0
    bootable: true
    flags: active confirmed
    hash: 9be8fdc14ede74d00442a50a6ecfb62939b41662b4459a6e63873b66b01a8f94
Split status: N/A (0)

  

Image upload:

$ mcumgr --conntype serial --connstring "/dev/ttyACM1,baud=115200" image upload zephyr/app_update.bin 
 58.12 KiB / 58.12 KiB [====================================================================================] 100.00% 3.64 KiB/s 15s
Done

 

You might want to check your UART hardware flow control settings, and also ensure that the serial terminal (putty, teraterm etc) is closed before you call mcumgr.

 

Kind regards,

Håkon

[kudo]

Hi Håkon,

Sorry for the late reply.

Windows PC - mcumgr image list communication between nRF5340-DK was successful.
When it previously failed on a Windows PC, as you pointed out, it was because the serial terminal was using the port.

However, it fails between Linux - nRF5340 modules.
Linux - It was successful between nRF5340-DK, so I think it's a problem with the nRF5340 module.
Is there a pin setting when using DFU?
(e.g. RESET pin etc.)

[Håkon Alseth]

Hi,

 

Q1: Does your module have an external 32k?

If not; you should set:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

Note that this should also be set in hci_rpmsg:

my_project/child_image/hci_rpmsg.conf

and mcuboot:

my_project/child_image/mcuboot.conf

 

Q2: Does your module have DCDC inductors in-place?

If not, you need to set:

CONFIG_BOARD_ENABLE_DCDC_APP=n
CONFIG_BOARD_ENABLE_DCDC_NET=n
CONFIG_BOARD_ENABLE_DCDC_HV=n

 

This also applies to any child_image's, as described above.

 

Q3: 

kudo said:

However, it fails between Linux - nRF5340 modules.

I assume this also means that windows is failing on these modules?

 

kudo said:

Is there a pin setting when using DFU?

When using smp_svr, it is the application that handles DFU, so no need to use any GPIO.

If you are using mcuboot recovery, ie. application is unaware of DFU, then you use a GPIO or a trigger to enter mcuboot recovery mode.

 

Kind regards,

Håkon

[kudo]

Hi Håkon,

Thank you for the information. solved.

There is no external 32k on the module, it uses an internal clock.

After adding the file below containing the clock settings as you pointed out, mcumgr communication was successful.

my_project/child_image/hci_rpmsg.conf

my_project/child_image/mcuboot.conf

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

[Håkon Alseth]

Hi,

 

I am glad to hear that the issue was solved, and that you took the time to write a reply with the fix to your issue.

If you have any more issues or questions, feel free to contact us at support again.

 

I hope you have a wonderful weekend!

 

Kind regards,

Håkon