Lpuart on the 5340 using interrupt mode fails to recover from a TX timeout

[kseegmiller]

I am using the lpuart between an nRF5340DK and an nRF9160DK.The lpuart is configured to operate in interrupt mode. Everything seems to work fine as long both DK boards come up at the same time. However, if the nRF9160DK takes a while to come up and the nRF5340Dk tries to send data over the lpuart it will timeout, as expected. But once the nRF9160DK is operational, the lpuart tx on the nRF5340 will no loner try to send. I tracked the issue down to a CAS (compare and set) call in the  uart_fiffo_fill function. Because the previous TX timed out, data->int_driven.txlen still holds the previous send attempt data length and this causes the CAS to fail and no send attempt is made. There appears to be no way to recover form this aside from rebooting the device. Stepping through the lpuart driver I found the int_driven_evt_handler() function is called with an event type of UART_TX_ABORTED which is not handled. For debugging purposes, I added  a UART_TX_ABORTED handler and just set the txlen to zero as it would do in the async mode. This seemed to solve the problem i.e. all lpuart sends would timeout until the nRF9160DK became operational at which point all data transfers between the two devices resumed normally. So my question is, are there other ways to recover from an lpuart TX timeout while operating in interrupt mode?

[Kenneth]

Hello,

Not sure if I can think of a better workaround, do you have any logic analyzer trace of the tx, rx, rdy and req pin when failing and working for comparison? does adding an external pull up on rdy or req make any difference? what is the timeout used here, does increasing it help?

Kenneth

[kseegmiller]

I have not considered an external pull up on the control lines as it doesn't seem to be the root of the issue. If you have additional data that would support using pull ups I would like to see it. Also, increasing the timeout will only kick the can down the road in my opinion and would not be a viable solution for this device. I have attached some traces for you to look at. One with the uart_nrf_sw_lpuart.c unmodified and the other with the modification of adding support for the UART_TX_ABORTED event in the int_driven_evt_handler(). The only thing the UART_TX_ABORED  code does is to set the txLen to zero.

	case UART_TX_ABORTED:
		LOG_DBG("tx aborted");
		data->int_driven.txlen = 0;
		call_handler = true;
		break;

Failure-with-lpuart-mod.sal

Lpuart-tx-timeout-no-recover.sal

--Kyle

[kseegmiller]

Is there a way to pull an SDK driver file into my local source, use that file rather than the one in the SDK? This way I can make the modification needed where it can be tracked.

--Kyle

[Kenneth]

Hi again,

The logic analyzer trace helped, there is no need to perform test with pull-up or longer timeout based on this trace.

I have been reading how the actual flow control is occuring in the lpuart driver:
https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.2/nrf/drivers/uart_nrf_sw_lpuart.html#control-protocol 

I suspect the root problem in this case is that the nRF9160 lpuart driver rely on receiving a rising edge on the RDY line (this is handled by the gpiote hardware peripheral), however if the nRF9160 power up after the RDY line went high, the nRF9160 don't get the rising edge on RDY line and you end up with a timeout on the transmitter. Unfortunately it seems that the transmitter is not able to gracefully recover from this situation, your workaround by simply reset the .txlen to workaround this issue seems like a good approach if you ask me, though a longer term workaround could be that the lpuart driver could check if the RDY line was already high on startup and based on that not wait for the rising edge on RDY line (though I have not looked into how that could be implemented, at the moment all rely on that rising edge in the first place).

I think the best I can do at the moment is to report it internally so some of the developers can look into making an appropriate fix for this in future.

kseegmiller said:

Is there a way to pull an SDK driver file into my local source, use that file rather than the one in the SDK? This way I can make the modification needed where it can be tracked.

Check out:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.4.2/zephyr/samples/application_development/out_of_tree_driver/README.html 

Kenneth