CLI buffer problem

[ninochila]

Hi everyone,

I'm using ble_app_interactive (SDK17.0.2) as a starting point for my application, which consists in sending commands from my PC to my nRF52DK, which is in charge to perform several BLE operations. I send the following commands to read some data from my BLE commercial device:

scan on

gatt services XX:XX:XX:XX:XX:XX

gatt characteristics XX:XX:XX:XX:XX:XX YYYY

gatt notification on XX:XX:XX:XX:XX:XX YYYY

It is all good until occur some problems with the buffering of the command that I sent. As echo messages, I sometimes get things such as:

gatt read D1:97:3C:2F:2F:C4 6f87:BF

where "87:BF" is a part of a previous command that I sent several seconds before the current command. 

It seems there is a problem of buffering the command, so when this buffer is full, some parts of previous command appears concatenated with the current command. If I well understand, there is a ring buffer that implement the buffer for this commands, which seems to be initialized with:

NRF_CLI_UART_DEF(m_cli_uart_transport, 0, 256, 256);

in the main file of the ble_app_interactive example. If it is responsible for this buffering, is there a way to reset it whenever I need, in order to avoid the above problem?

 

[Jørgen Holmefjord]

Hi,

It looks like the example uses the following define by default:

NRF_CLI_UART_DEF(m_cli_uart_transport, 0, 64, 16);

Did you modify the buffer sizes? Have you seen the same issue with default settings?

Are you using Putty with the recommended Terminal settings to test this?

Best regards,
Jørgen

[Jørgen Holmefjord]

This kind of issue is typically caused by missing string termination character (\0) and/or '\r'/'\n'. Are you sure these are handled correctly in your application sending/receiving the commands?

The CLI should have separate buffers for TX and RX, so I'm not sure how the command you send could get into the response. Are you using separate buffers for sending and receiving to/from the serial port in your application?

[ninochila]

--"This kind of issue is typically caused by missing string termination character (\0) and/or '\r'/'\n'. Are you sure these are handled correctly in your application sending/receiving the commands?"

Should I use both "\n" "\r"?

I think in my application its all correct with termination characters, because the issue I tell you happen in a random manner, often the device communicate correctly all the information that I need, just sometimes the problem appear. If there would be a termination problem, it will appear in a sistematic manner, I think.

--"The CLI should have separate buffers for TX and RX, so I'm not sure how the command you send could get into the response. Are you using separate buffers for sending and receiving to/from the serial port in your application?"

The issue is in the echo that I receive from the nrf52DK, so I supposed that what I receive from the PC in the echo is equivalent to what the nrf52DK store in the receive buffer, so I think the problem is in the receive buffer and just replying the echo to the pc it appears in the trasmitting buffer. Another thing that confirm that the problem is in the receiving buffer, is that the nrf52DK reply (just when the problem occur) with the info: "command not found" or "Invalid parameter" and so on, depending in what particular command the error appear. It seems the receive buffer is full and start to overwrite on old data, what do you think? so I would reset the receive buffer, if possible.

The serial communication from my app running on the PC to nrf52DK has been verified with a terminal monitor, and the commands are sent correctly.

[Jørgen Holmefjord]

ninochila said:

--"This kind of issue is typically caused by missing string termination character (\0) and/or '\r'/'\n'. Are you sure these are handled correctly in your application sending/receiving the commands?"

Should I use both "\n" "\r"?

For UART, you should use "\r", see Usage.

ninochila said:

I think in my application its all correct with termination characters, because the issue I tell you happen in a random manner, often the device communicate correctly all the information that I need, just sometimes the problem appear. If there would be a termination problem, it will appear in a sistematic manner, I think.

It could happen if you are using a circular buffer and reaches the end of the buffer, but miss the newline character when calculating the size of the string. A simple check regarding this could be to use a logic analyzer to see what is transmitted over the UART lines. Then you should see if all newline characters are sent correctly.

ninochila said:

--"The CLI should have separate buffers for TX and RX, so I'm not sure how the command you send could get into the response. Are you using separate buffers for sending and receiving to/from the serial port in your application?"

The issue is in the echo that I receive from the nrf52DK, so I supposed that what I receive from the PC in the echo is equivalent to what the nrf52DK store in the receive buffer, so I think the problem is in the receive buffer and just replying the echo to the pc it appears in the trasmitting buffer. Another thing that confirm that the problem is in the receiving buffer, is that the nrf52DK reply (just when the problem occur) with the info: "command not found" or "Invalid parameter" and so on, depending in what particular command the error appear. It seems the receive buffer is full and start to overwrite on old data, what do you think? so I would reset the receive buffer, if possible.

It is possible. If there is an issue with the receive buffers, this should be reproducible with a given set of commands (a given number of received bytes). Could you try to find a set of commands that will reproduce the issue, that we can use to reproduce it on our side?