nRF52832 Bluetooth peripheral_uart sample: use RX data and not sent to BLE

[BradEA]

I want to intercept some data in the RX (in section UART_RX_READY in uart_cb() as a command with arguments.  And I do not want this data to be sent on the the BLE.

After I get the data that I want, what should I do with the buf, so the process continues getting new data from the UART RX?

Do I just k_free(buf)?  Or something else?

[Karl Ylvisaker]

Hello,

You can input your specific checks for the commands in the handling of the UART_RX_BUF_RELEASED event.
If you omit the call to k_fifo_put(&fifo_uart_rx_data, buf); it will not be sent over BLE.
If you wish to discard the data afterwards you call k_free(buf) to free the buffer, correct.

Best regards,
Karl

[BradEA]

I moved by command handling code to the UART_RX_BUF_RELEASED section.  At the end I set buf->len = 0, so the buf will be freed, k_free(buf).  But something still seems to be around because I get the following when I switch back to "data mode" and connect to a tablet running nRF Connect:

RING:CONNECTED
[00:10:15.156,921] <inf> peripheral_uart: Connected 43:76:74:54:A2:83 (random)
[00:11:36.653,747] <wrn> bt_att: No ATT channel for MTU 39
[00:11:36.653,778] <wrn> bt_gatt: No buffer available to send notification
[00:11:36.653,869] <wrn> peripheral_uart: Failed to send data over BLE connection

[BradEA]

I went back and found that the above was due to not using the proper steps when I would be using command mode.

I propose to use the following steps:

1. Disconnect the BLE link
2. Change to Command Mode
3. send the commands to the radio uart
4. Change back to Data Mode
5. Connect to the BLE link

[BradEA]

Is this how the Rx works?

• data comes into the UART
• uart causes interrupt for every byte it receives
• interrupt causes evt of type UART_RX_RDY via notify_rx_buffer()?
• uart_cb() handles these events
• data is in evt->data.rx.buf, len is in evt->rx.len (always 1?)
• if all data to termination (\r, \n), then call uart_rx_disable(uart) and disable_req = true
• not sure what all goes on, but I presume we end up in uart_cb() again at UART_RX_BUF_RELEASED
  • seems there is a new buffer, evt->data.rx_buf.buf?
• data is transferred to fifo_uart_rx_data (another buffer) if there is data, otherwise k_free(buf)
• thread ble_write_thread() detects and sends to bt_nus_send()
• here the len can be no longer than what bt_nus_get_mtu() returns

How do the following get attention?:

• UART_RX_DISABLED 

  UART_RX_BUF_REQUEST

  Where is the size of these buffers determined?

  What process controls the RTS line for the uart's rx buffer?

[Karl Ylvisaker]

Hello again,

BradEA said:

Is this how the Rx works?

Almost, with a few amendments:

BradEA said:

uart causes interrupt for every byte it receives

Not quite - it causes an interrupt for every tranfer it received. The transfer might be longer than 1 byte.
You can test this by sending multiple characters from your serial terminal at once.

BradEA said:

data is in evt->data.rx.buf, len is in evt->rx.len (always 1?)

No, because the length of the transfer could be longer than 1.

BradEA said:

interrupt causes evt of type UART_RX_RDY via notify_rx_buffer()?

This depends on whether the UART driver is operating in asynchronous mode or not, but yes.

BradEA said:

not sure what all goes on, but I presume we end up in uart_cb() again at UART_RX_BUF_RELEASED

The new buffer is actually set as part of the handling for the UART_RX_DISABLED event, which is generated at the end of the UART_RX_RDY event.
A new buffer can also be made as part of the UART_RX_BUF_REQUEST event handling, if required.

BradEA said:

here the len can be no longer than what bt_nus_get_mtu() returns

The len can be longer than the MTU size - this will make the data be split and transferred over multiple packets. The SoftDevice Controller will handle this for you. The UART buffer is however set to be the same as the NUS buffer - UART_BUF_SIZE, so you can not exceed that.

BradEA said:

UART_RX_DISABLED 

UART_RX_BUF_REQUEST

UART_RX_DISABLED is raised at the end of the UART_RX_RDY event handling.
UART_RX_BUF_REQUEST is used to request a new buffer, you can see how it is used by going into the uart_nrfx_uart.c source code's rx_isr function.

BradEA said:

Where is the size of these buffers determined?

They are defined at the beginning of main.c in this case.

BradEA said:

What process controls the RTS line for the uart's rx buffer?

If enabled then the UART peripheral itself will control this. It is the CTS (clear to send) that is related to the RX buffer on the receiving device.

Best regards,
Karl

[BradEA]

RTS line control:  Is this not the uart's output line that when high signals the sender that the uart cannot receive any more characters on its RX line?

CTS line: uart input indicating the uart may send characters out TX line when low?  All the code I've looked at has the CTS line as an input with an optional pullup.

So my question regarding the RTS line: what actually controls the state of the RTS line?

You indicated that this sample uses "uart_nrfx_uart.c", How should the uart be defined in prj.conf:

CONFIG_NRFX_UART0=y  or

CONFIG_NRFX_UARTE0=y?

AND  CONFIG_BT_NUS_UART_ASYNC_ADAPTER=y?

Would it be appropriate to send the project so you can see what I may have messed up?  When I send a long string of characters (54 long), I get this: (I added the BufLen and Ble_Mtu_size printouts)

It dropped some chars and nothing shows up on the tablet.

12345678901234567890123456789012345678901234567890FEFF[00:04:27.464,508] <inf> peripheral_uart: BufLen: 1, Ble_Mtu_size: 20
--- 4 messages dropped ---
[00:04:27.465,179] <inf> peripheral_uart: BufLen: 8, Ble_Mtu_size: 20
[00:04:27.465,301] <inf> peripheral_uart: BufLen: 10, Ble_Mtu_size: 20
[00:04:27.465,423] <inf> peripheral_uart: BufLen: 11, Ble_Mtu_size: 20
[00:04:27.465,545] <inf> peripheral_uart: BufLen: 13, Ble_Mtu_size: 20
[00:04:27.465,667] <inf> peripheral_uart: BufLen: 14, Ble_Mtu_size: 20
[00:04:27.465,789] <inf> peripheral_uart: BufLen: 15, Ble_Mtu_size: 20
[00:04:27.465,911] <inf> peripheral_uart: BufLen: 16, Ble_Mtu_size: 20
[00:04:27.466,033] <inf> peripheral_uart: BufLen: 17, Ble_Mtu_size: 20
[00:04:27.466,156] <inf> peripheral_uart: BufLen: 19, Ble_Mtu_size: 20
[00:04:27.466,278] <inf> peripheral_uart: BufLen: 20, Ble_Mtu_size: 20
[00:04:27.466,949] <wrn> bt_att: No ATT channel for MTU 31
[00:04:27.466,979] <wrn> bt_gatt: No buffer available to send notification
[00:04:27.467,041] <wrn> peripheral_uart: Failed to send data over BLE connection
[00:04:27.467,163] <inf> peripheral_uart: BufLen: 2, Ble_Mtu_size: 20
[00:04:27.467,285] <inf> peripheral_uart: BufLen: 3, Ble_Mtu_size: 20
[00:04:27.467,437] <inf> peripheral_uart: BufLen: 5, Ble_Mtu_size: 20
[00:04:27.467,559] <inf> peripheral_uart: BufLen: 6, Ble_Mtu_size: 20
[00:04:27.467,681] <inf> peripheral_uart: BufLen: 7, Ble_Mtu_size: 20
[00:04:27.467,803] <inf> peripheral_uart: BufLen: 9, Ble_Mtu_size: 20
[00:04:27.467,926] <inf> peripheral_uart: BufLen: 10, Ble_Mtu_size: 20
[00:04:27.468,048] <inf> peripheral_uart: BufLen: 12, Ble_Mtu_size: 20
[00:04:27.468,170] <inf> peripheral_uart: BufLen: 13, Ble_Mtu_size: 20
[00:04:27.468,292] <inf> peripheral_uart: BufLen: 14, Ble_Mtu_size: 20
[00:04:27.468,414] <inf> peripheral_uart: BufLen: 16, Ble_Mtu_size: 20
[00:04:27.468,536] <inf> peripheral_uart: BufLen: 17, Ble_Mtu_size: 20
[00:04:27.468,658] <inf> peripheral_uart: BufLen: 19, Ble_Mtu_size: 20
[00:04:27.468,780] <inf> peripheral_uart: BufLen: 20, Ble_Mtu_size: 20
[00:04:27.469,482] <wrn> bt_att: No ATT channel for MTU 28
[00:04:27.469,482] <wrn> bt_gatt: No buffer available to send notification
[00:04:27.469,512] <wrn> peripheral_uart: Failed to send data over BLE connection