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

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

Kenneth — Wed, 18 Oct 2023 20:33:28 GMT

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.

[quote userid="88759" url="~/f/nordic-q-a/104794/lpuart-on-the-5340-using-interrupt-mode-fails-to-recover-from-a-tx-timeout/451132"]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.[/quote]

Check out:

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

Kenneth

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

kseegmiller — Wed, 18 Oct 2023 19:01:46 GMT

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

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

kseegmiller — Wed, 18 Oct 2023 18:52:53 GMT

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;

devzone.nordicsemi.com/.../Failure_2D00_with_2D00_lpuart_2D00_mod.sal

devzone.nordicsemi.com/.../Lpuart_2D00_tx_2D00_timeout_2D00_no_2D00_recover.sal

--Kyle

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

Kenneth — Wed, 18 Oct 2023 09:25:56 GMT

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