Serial communication in different modes

[nrbrook]

I'm implementing communication with an MCU via UART. There are two types of communication – messages, and MCU DFU data. Messages are <256 bytes of data. MCU DFU is >50kb data and is already implemented on the MCU using XModem. When a DFU start message is sent to the MCU from the nRF, the protocol will switch to Xmodem and the nRF will send the MCU DFU data.

We have chosen MIN as the wire protocol for messages as a reliable transport. The MIN C API works as follows:

• RX: on data received, pass a variable length data buffer to min_poll
• TX: min_tx_space callback to return available buffer length, min_tx_start, min_tx_byte (multiple calls), and min_tx_finished callbacks to send data

The XModem API works as follows:

• RX: callback to receive a single byte with timeout
• TX: callback to send a single byte with timeout

I need to implement these on the nRF. After evaluating the myriad of libraries (UART, UARTE, Serial, libuarte) it seems nrf_libuarte_async is most appropriate for the MIN messages, is this correct?

How can I switch from this async mode of operation to a synchronous mode of operation with XModem?

[Håkon]

Hi,

To me it looks like the nrf_libuarte_async is a good fit for your use case and the MIN protocol, since messages are sent async and the MIN protocol supports messages of different length. 

I am not sure I understand what you mean when you say you would like to switch to synchronous operation. To me it looks like the synchronous operation required by the XModem protocol is something that must be implemented in your application. Since you know the amount of bytes being sent and (N)ACKs returned it sounds like you can manage without the async timeout handling while in MCU DFU mode. It is possible to uninit the libarute_async and initialize e.g. the libarte_drv lib, then switch back to libuarte_async when done in the MCU DFU mode.

Regard,
Håkon

[nrbrook]

Bug report: In nrf_libuarte_async.c, line 389.

Prints lowest priority as APP_IRQ_PRIORITY_LOW, but if app_timer is used then lowest priority is APP_TIMER_CONFIG_IRQ_PRIORITY - 1

[Håkon]

Hi,
I am not sure why our SDK team has done it this way, but indeed it seems odd.
I'll forward this to them and let you know their response. 

[nrbrook]

It was confusing because it logged priority must be lowest 6, but the priority was 6 already. I had to change the libuarte priority to 5 (which is different from libuarte example, perhaps the example is broken as APP_TIMER_CONFIG_IRQ_PRIORITY is 6 in the example too and the example uses app_timer)

[Håkon]

This is strange, and needs to be looked into. Thanks for your findings so far. Does it seem to work for you now with this modification?

[nrbrook]

Yes. libuarte is just what I needed, thanks. It would have saved me a lot of time if there was a summary of the different UART libraries and their intended use cases. It seems like the serial library could be deprecated.