Serial communication in different modes

RE: Serial communication in different modes

nrbrook — Fri, 17 Jan 2020 15:15:03 GMT

Ah yes, so it does, I got confused with the parameters. That is probably why the IRQ priority issue has gone under the radar.

Calling nrf_libuarte_async_enable twice was a mistake, but the function does not check if the instance has already been enabled, so the resulting error is confusing.

RE: Serial communication in different modes

nrbrook — Fri, 17 Jan 2020 15:07:48 GMT

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.

RE: Serial communication in different modes

Håkon — Thu, 16 Jan 2020 18:27:11 GMT

Which SDK are you using?
In SDK 16.0.0, the example in perhipheral/libuarte uses RTC by default for timeout. The selection is done in line 60 in main.c

NRF_LIBUARTE_ASYNC_DEFINE(libuarte, 0, 0, 0, NRF_LIBUARTE_PERIPHERAL_NOT_USED, 255, 3);

However, a timer is used as well for counting bytes.

I was under the impression that nrf_libuarte_async_unitnit(...) would free up all used peripherals. Did you uninitialize using this function before trying to init again?

RE: Serial communication in different modes

Håkon — Thu, 16 Jan 2020 17:52:39 GMT

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?

RE: Serial communication in different modes

nrbrook — Thu, 16 Jan 2020 17:41:39 GMT

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)

RE: Serial communication in different modes

Håkon — Thu, 16 Jan 2020 17:38:15 GMT

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.

RE: Serial communication in different modes

nrbrook — Thu, 16 Jan 2020 14:02:29 GMT

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

RE: Serial communication in different modes

nrbrook — Thu, 16 Jan 2020 14:00:45 GMT

I was calling nrf_libuarte_async_enable twice, there should probably be a check in nrf_libuarte_async_enable for this.

RE: Serial communication in different modes

nrbrook — Thu, 16 Jan 2020 13:46:11 GMT

Is there an example using libuarte with RTC and timer instead of app timer? It's hitting the ASSERT in nrfx_timer.c:143

m_cb[p_instance->instance_id].state == NRFX_DRV_STATE_INITIALIZED

RE: Serial communication in different modes

nrbrook — Wed, 15 Jan 2020 22:32:13 GMT

Thanks, I’ll have a go at this.

RE: Serial communication in different modes

Håkon — Wed, 15 Jan 2020 20:11:34 GMT

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