Sharing UART between DFU & APP

[BZK]

I am using the UART to perform serial DFU on nRF52832. I got it to work fine using nRF Connect SDK 1.8.0.

Now, I need to pass some serial data to the APP when not in DFU mode. I am using:

# Enable the serial mcumgr transport.

CONFIG_MCUMGR_SMP_UART=y

# Enable console with mcumgr pass through

CONFIG_CONSOLE=y

CONFIG_UART_CONSOLE=y

CONFIG_UART_CONSOLE_MCUMGR=y

I can't find a way to get the APP to read the UART receiver successfully.

I have tried to check the UART using: uart_poll_in(uart_dev, uart_buffer) but it always returns -1 even though normal ASCII data (not DFU data) is being sent serially to the nRF chip.

I don't want to use the "SHELL" module, as it is an overkill for my application.

How do you share the UART between SMP & APP, i.e. how should the UART be initialized and accessed by the APP without breaking the serial DFU capability?

[Einar Thorsrud]

Hi,

The mcumgr is part of the application as well (and not the bootloader), and you cannot use a single UART instance for two separate things at the same time. Do you only need the other UART for debugging? If so, the most straightforward would be do avoid UART for that, and use RTT instead.

[BZK]

I don't need the UART for debugging.

I need to use the UART to communicate between a simple nRF52832 module and another Wi-Fi module on regular basis.

Now, if the need arises, the Wi-Fi module can perform the DFU operation on the nRF chip to update its App. But this is a rare operation, and when this update becomes required, the App would relinquish the UART to the mcumgr to finish the DFU operation.

I am thinking, since it is possible to share the UART between the SHELL and DFU subsystems, as indicated in the SMP-SVR sample (via CONFIG_MCUMGR_SMP_SHELL=y), how can I get such sharing without using SHELL?

Thanks.

[Einar Thorsrud]

Hi,

I see. RTT is no option, then.

The feature for passthrough mcumgr is implemented in the shell and is specific for that. The SDK does not have a generic way of sharing UART or any other way. If you need this, you would have to implement it yourself.

Alternatively, perhaps you could for instance use the serial recovery feature of MCUBoot, so that there is no DFU related code in the application itself? In that case, you would need a way to trigger serial recovery from the WiFi chip (like resetting and asserting a pin during nRF boot), and then avoid this issue altogether? I do not know about your WiFi device, but yet another option could perhaps be to use another interface like SPI, if that is available.

[BZK]

Thanks for your help.