won't get RX Timeout on peripheral and central uart example

RE: won't get RX Timeout on peripheral and central uart example

steveqin — Sat, 03 Jun 2023 14:44:14 GMT

Edvin,

Thank you very much! this fixed the timeout issue.

Thank you very much again,

Steve

RE: won't get RX Timeout on peripheral and central uart example

Edvin — Thu, 01 Jun 2023 13:20:25 GMT

I see.

Disclaimer: I tested this in NCS v2.4.0, which was released today, but I believe the sample is equivalent in v2.3.0, apart from that you need to consider that the timeout is in µs and not ms.

I see that one instance of uart_rx_enable() uses a hardcoded 50, instead of UART_WAIT_FOR_RX, so you may want to replace that.

Then, in your UART_RX_DISABLED event in uart_cb(), you will see:

	case UART_RX_RDY:
		LOG_DBG("UART_RX_RDY");
		buf = CONTAINER_OF(evt->data.rx.buf, struct uart_data_t, data);
		buf->len += evt->data.rx.len;

		if (disable_req) {
			return;
		}

		 if ((evt->data.rx.buf[buf->len - 1] == '\n') ||
		     (evt->data.rx.buf[buf->len - 1] == '\r')) {
			disable_req = true;
			uart_rx_disable(uart);
		 }

		break;

So this event will trigger after UART_WAIT_FOR_RX has timed out, but it will only disable the uart using uart_rx_disable(), which again will trigger the transmission of the UART data over BLE. This will only happen if the last byte is '\r' or '\n', regardless of whether the UART has timed out or not. So try to remove that check, and trigger uart_rx_disable(), and set disable_req=true regardless of the last bytes.

Alternatively, to check whether the interrupt occurs, you can change LOG_DBG() to LOG_INF(), and monitor the RTT log to see whether the callback is triggered.

Best regards,

Edvin

RE: won't get RX Timeout on peripheral and central uart example

steveqin — Tue, 30 May 2023 13:37:31 GMT

I just test it, the timeout still doesn't work, could you let me know your test result? I really want to fix this problem.

thank you very much,

Steve

RE: won't get RX Timeout on peripheral and central uart example

Edvin — Tue, 30 May 2023 07:27:46 GMT

Sorry. I forgot that this was part of the UART library in NCS/Zephyr (it was not in the "old" nRF5 SDK).

Note that there is in fact a bug here. The input number (100 in your case), is given in microsecons, not millisecons. So try increasing it a bit.

This bug, where the sample uses ms and the SDK uses microseconds is reported, and will be fixed in a future release. It was introduced when Zephyr went from ms to µs, a couple of releases ago.

If you wanted to test with 100ms, try using the value 100000, and see if it behaves like you would expect.

Best regards,

Edvin

RE: won't get RX Timeout on peripheral and central uart example

steveqin — Fri, 26 May 2023 13:46:14 GMT

is this a bug? Can Nordic fix it? if there is no timeout why does this protocol still have a timeout parameter?

uart_rx_enable(uart ,rx_buf,sizeof rx_buf,100);

The last parameter is the timeout, which in the context of the uart_rx_enable() function will determine how fast we get notified on incoming data that is less than the whole buffer size. It is called the inactivity period, which is measured after receiving at least a byte. Pick a value that fits your application’s requirements. You can also disable the timeout by passing SYS_FOREVER_US.

Thanks,

RE: won't get RX Timeout on peripheral and central uart example

Edvin — Fri, 26 May 2023 13:32:32 GMT

Hello,

There is no timeout by default in UART. The protocol just sends byte by byte. I recommend that you set up a timer that you can reset whenever you receive a byte. If the timer times out, you can consider the message complete.

I guess you knew, but another possibility is to use a special character at the end of all messages, such as linefeed (\n - 0x0A), and use this to trigger the message complete action.

Best regards,

Edvin