LPUART Issues with NRF52 - SLM

Question

NRF52: SDK v2.1.1

NRF91/SLM: SDK v2.0.0

We are seeing an issue with NRF52840 / NRF91 interaction over LPUART. When NRF91 powers up, the bootloader is not using using LPUART and prints the bootline. When SLM boots, it starts communicating using LPUART. There may be an issue with such a transition because we're seeing the following:

00> rtt:~$ [00:00:00.051,788] <dbg> modem_cmd_handler: modem_cmd_send_ext: SENT DATA
00> rtt:~$ [00:00:00.051,818] <dbg> lpuart: api_tx: tx len:1
00> rtt:~$ [00:00:00.749,572] <dbg> lpuart: rdy_pin_handler: RX: Request detected.
00> rtt:~$ [00:00:00.750,091] <dbg> lpuart: activate_rx: RX: Ready
00> rtt:~$ rtt:~$ [00:00:01.180,541] <dbg> lpuart: uart_callback: RX: Ready buf:0x20007164, offset: 0,len: 47
00> rtt:~$ [00:00:01.180,877] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: RECV
00> 2a 2a 2a 20 42 6f 6f 74 69 6e 67 20 5a 65 70 68 |*** Boot ing Zeph
00> 79 72 20 4f 53 20 62 75 69 6c 64 20 30 61 39 30 |yr OS bu ild 0a90
00> 34 64 30 63 31 37 36 61 20 20 2a 2a 2a |4d0c176a ***
00> rtt:~$ [00:00:01.180,999] <dbg> modem_cmd_handler: cmd_handler_process_rx_buf: match cmd [] (len:45)
00> rtt:~$ [00:00:01.263,946] <dbg> lpuart: req_pin_handler: TX: Confirmed, starting.
00> rtt:~$ [00:00:01.264,068] <dbg> lpuart: tx_complete: TX completed, pin idle
00> rtt:~$ [00:00:01.265,258] <dbg> lpuart: api_tx: tx len:1
00> rtt:~$ [00:00:01.267,395] <dbg> lpuart: req_pin_handler: TX: Confirmed, starting.
00> rtt:~$ [00:00:01.267,547] <dbg> lpuart: tx_complete: TX completed, pin idle
00> rtt:~$ [00:00:02.334,930] <dbg> lpuart: uart_callback: RX: Ready buf:0x20007164, offset: 47,len: 47
00> rtt:~$ rtt:~$ [00:00:06.315,551] <err> modem_cmd_handler: command ret:-116
00> rtt:~$ rtt:~$ [00:00:16.315,704] <wrn> modem_nrf91: Reseting nrf91 modem
00> rtt:~$ [00:00:16.415,985] <inf> modem_nrf91: Sending AT, waiting for OK
00> rtt:~$ [00:00:16.416,076] <dbg> modem_cmd_handler: modem_cmd_send_ext: SENT DATA
00> 41 54 |AT
00> rtt:~$ [00:00:16.416,107] <dbg> lpuart: api_tx: tx len:1

// this log line is added right before the assert in int_driven_evt_handler in UART_RX_RDY
00> rtt:~$ rtt:~$ RX: rx.len 5 vs int.rxlen 47 bytes
00> [00:00:17.427,734] <dbg> lpuart: rdy_pin_handler: RX: End detected.

The code asserts in int_driven_evt_handler on line __ASSERT_NO_MSG(data->int_driven.rxlen == 0); We actually had to disable this assert to even get through this. case UART_RX_RDY:

// __ASSERT_NO_MSG(data->int_driven.rxlen == 0);

printk("RX: rx.len %d vs int.rxlen %d bytes\n", evt->data.rx.len,

data->int_driven.rxlen);

But that presents another challenge because rxlen is changed without resetting rxrd, which creates and underflow in int_driven_rd_available, which I updated like so:

static uint32_t int_driven_rd_available(struct lpuart_data *data)

{

if (data->int_driven.rxlen < data->int_driven.rxrd) {

return 0;

}

return data->int_driven.rxlen - data->int_driven.rxrd;

}

It appears that when SLM boots up, it sends Ready but the bootloader never terminated its transmission of the boot banner (because it's not using LPUART).

My changes appear to get us back on track but I don't like to have to tweak nordic supplied code. What's the recommended way to proceed here?