MCUMGR - sends responses to wrong port

Lawrence King

Dear All:


I am trying to setup mcumgr to allow code download over a serial port and use the shell. In this case I have 2 serial ports in play.


The first serial port is where printk() sends messages. I also have a simple command parser on the port that interprets single letter commands. This printk and my command parser work as expected.


The second serial port is running a shell. Commands like ‘help’ and ‘fs ls’ work as expected, output appears on the second port. However when I attempt to send a file or image update using mcumgr to the second serial port, it doesn’t work. The initial packet arrives on the serial port, smp_shell recognizes the packet, formulates a response, and then sends the response to the first serial port, not the second serial port as it should. LOG messages also come out on the second port as expected.


I chased the  problem as far as I can. In smp_shell.c the function smp_shell_tx_raw() always sends the packet via k_str_out(). It should be sending the packet back by shell_print(). Unfortunately the function smp_shell_tx_raw doesn’t have access to the handle for the shell.


I did try setting CONFIG_UART_MCUMGR_ON_DEV_NAME but k_str_out() ignores this setting….


Any suggestions on how to fix this? Or am I doing something wrong?



Lawrence King

Principal Developer

Connected Transport Market Unit



1  2 - linkedin  3 - instagram  4 - youtube  6 - facebook  7


CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you.




Join { to automatically receive all group messages.