FOTA with OTBR and UDP

Hi all,

I'm trying to set up MCUMGR on 54L15, such that it can receive images from my border router when they're in the same Thread network. 

I read that we can upload images from our raspi given the IP address and port to send to.I think I've generated the signed dfu zips successfully, and I have set up the mcumgr command on the pi. Shown here:

>> `mcumgr --conntype udp --connstring [fdb4:4ee4:da2a:6d93:0:ff:fe00:6c00]:1337 image upload dfu/ot-light-base.signed.bin`

However, the upload progress never makes it past 0%. I'm thinking maybe I'm missing configurations in my project? I added more configurations (starting at line 56 in the code block below) related to MCUMGR transport with UDP, but when I run the program now, it halts whenever the Thread instance attaches to a network, and it shows an error related to SMP UDP?

CONFIG_APP_LIGHTS=y
# Network shell comment out to remove CLI functionality 
CONFIG_SHELL=y
CONFIG_OPENTHREAD_SHELL=y
CONFIG_SHELL_ARGC_MAX=26
CONFIG_SHELL_CMD_BUFF_SIZE=416

# Enable OpenThread features set
CONFIG_OPENTHREAD_NORDIC_LIBRARY_MASTER=y

CONFIG_NET_L2_OPENTHREAD=y
CONFIG_NETWORKING=y

#THREAD CONFIGS
CONFIG_OPENTHREAD=y
CONFIG_OPENTHREAD_SRP_CLIENT=y
CONFIG_OPENTHREAD_FTD=y
CONFIG_OPENTHREAD_JOINER=y
CONFIG_OPENTHREAD_COMMISSIONER=y

CONFIG_SERIAL=n

#RTT CONFIG (Comment out if uart is on)
CONFIG_LOG=y
CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y
CONFIG_SHELL_BACKEND_RTT=y
CONFIG_UART_CONSOLE=n
CONFIG_SHELL_BACKEND_SERIAL=n

#UART CONFIGS FOR RECEIVING COMMANDS (Comment out if rtt is on)
# CONFIG_LOG=y
# CONFIG_SERIAL=y
# CONFIG_UART_CONSOLE=y
# CONFIG_SHELL_BACKEND_SERIAL=y
# CONFIG_USE_SEGGER_RTT=n
# CONFIG_RTT_CONSOLE=n
# CONFIG_SHELL_BACKEND_RTT=n

CONFIG_OPENTHREAD_OPERATIONAL_DATASET_AUTO_INIT=n
CONFIG_OPENTHREAD_DEBUG=y
CONFIG_OPENTHREAD_LOG_LEVEL_DEBG=y

# Storage
CONFIG_SETTINGS_ZMS=y
CONFIG_ZMS=y
CONFIG_NVS=n
CONFIG_SPI_NOR=n
CONFIG_PWM=y

CONFIG_MAIN_STACK_SIZE=6144
CONFIG_SHELL_STACK_SIZE=1024

CONFIG_BOOTLOADER_MCUBOOT=y      # Enables image format compatibility

CONFIG_MCUMGR_TRANSPORT_UDP=y
CONFIG_MCUMGR_TRANSPORT_UDP_IPV6=y
CONFIG_NET_BUF=y
CONFIG_ZCBOR=y
CONFIG_CRC=y
CONFIG_MCUMGR=y

CONFIG_NET_SOCKETS=y
CONFIG_STATS=y
CONFIG_IMG_MANAGER=y
CONFIG_MCUMGR_GRP_IMG=y
CONFIG_MCUMGR_GRP_OS=y
CONFIG_MCUMGR_GRP_STAT=y
CONFIG_STREAM_FLASH=y

CONFIG_FLASH=y
CONFIG_FLASH_MAP=y

I'm thinking maybe enabling CONFIG_MCUMGR_SMP_UDP would change the situation here. I've read documentations on CONFIG_MCUMGR_SMP_UDP, but when I attempt to configure it in prj.conf, it is not recognized as a symbol, I failed to find more information as to why it isn't recognized here.

I would appreciate any help going forward. I'm not finding any recent discussions on this method of FOTA; the ones that I can find are all from long ago and many sample programs and pages have deprecated.

Best regards,

Allan

Parents
  • Hello,

    If you check the SMP specification, a 64-byte buffer might work for SMP over UART, since it deals with small, framed, base64-encoded packets with a size limit of around 127 bytes.

    But for SMP over UDP, this buffer size is likely too small. I suggest starting with a 512-byte buffer, and increasing it to 1024 bytes if you encounter issues like stalled uploads or dropped packets.

    Which SDK version is this, because the link you shared points to an old SDK version?

    Kind Regards,

    Abhijith

  • Hi,

    Increasing the buffer size did allow me to capture all of the bytes sent to me (I tried logging the bytes from a custom port, not 1337). However, it appears to me that I have not started the process correctly. I configured the SMP TRANSPORT UDP, and from the logs alone, I think it is starting correctly (the smp_udp module logged success):

    I also tried executing ping6 <ipv6> on the pi:

    279 packets transmitted, 233 received, 16.4875% packet loss, time 279378ms
    rtt min/avg/max/mdev = 12.510/16.910/28.840/3.133 ms

    The statistics above suggest that my device is indeed reachable, with occasional packet loss. 

    However, executing mcumgr commands result in a timeout. It never responds, and even if we try sending the packages, the process bar still gets stuck at 0%. 

    mcumgr --conntype udp --connstring [fdb4:4ee4:da2a:6d93:0:ff:fe00:b400]:1337 image list
    Error: NMP timeout

    mcumgr --conntype udp --connstring [fdb4:4ee4:da2a:6d93:0:ff:fe00:b400]:1337 im
    age upload dfu/ot-light-base.signed.bin
    0 B / 492.27 KiB [-------------------------------------------------------------------------] 0.00%

    I'd appreciate any help, thanks!

    Best regards,

    Allan

Reply
  • Hi,

    Increasing the buffer size did allow me to capture all of the bytes sent to me (I tried logging the bytes from a custom port, not 1337). However, it appears to me that I have not started the process correctly. I configured the SMP TRANSPORT UDP, and from the logs alone, I think it is starting correctly (the smp_udp module logged success):

    I also tried executing ping6 <ipv6> on the pi:

    279 packets transmitted, 233 received, 16.4875% packet loss, time 279378ms
    rtt min/avg/max/mdev = 12.510/16.910/28.840/3.133 ms

    The statistics above suggest that my device is indeed reachable, with occasional packet loss. 

    However, executing mcumgr commands result in a timeout. It never responds, and even if we try sending the packages, the process bar still gets stuck at 0%. 

    mcumgr --conntype udp --connstring [fdb4:4ee4:da2a:6d93:0:ff:fe00:b400]:1337 image list
    Error: NMP timeout

    mcumgr --conntype udp --connstring [fdb4:4ee4:da2a:6d93:0:ff:fe00:b400]:1337 im
    age upload dfu/ot-light-base.signed.bin
    0 B / 492.27 KiB [-------------------------------------------------------------------------] 0.00%

    I'd appreciate any help, thanks!

    Best regards,

    Allan

Children
No Data
Related