nrf52840 interactive command uart flushing

[yu1998]

sdk17.0.2

so i am trying to flush rx/tx while the command execute

cannot find 

app_fifo_flush()

or

app_uart_flush()

anyone know how to do it?

[ovrebekk]

Hi 

Are you using one of the standard SDK examples?

There is an app_uart_flush() function for flushing the buffers when using the app_uart driver, but it will not do anything unless you make sure to use the app_uart_fifo.c implementation. 

When you say you cannot find this function, do you mean that the build fails if you try to call it?

The function is declared on line 244 of app_uart.h, and implemented on line 186 of app_uart_fifo.c

Best regards
Torbjørn

[yu1998]

hello  I am using standard sdk but still cannot find both of those 

app_uart.h,  app_uart_fifo.c in interactice command  

sdk17.0.2

[ovrebekk]

Hi

I don't think there is any way to flush the UART buffers when using CLI. 

Is there a particular reason you need to do this?
Do you just need to know when the command is finished?

Best regards
Torbjørn

[yu1998]

you  mean I cannot clear the  uart_rx tx

ovrebekk

I mean I found a bug happened it randomly

for example sometimes when I type on the keyboard "connect AF:BF:CF:DF:EF:FF" but when I type to con or connect when I press the next character it with output random character on the uart so I wonder why is this happening(Seldom happen)

another thing is if I just copy-paste "connect AF:BF:CF:DF:EF:FF"     

sometimes  the output show up on uart wrong 

it shows "connect??? AF:???BF:C???F:DF:EF:FF"

I am 100% sure I copy the correct string 

for example

[15:06:31.505]OUT↙⊙connect 5C:F3:70:38:AE:36 

↓
[15:06:31.508]IN↘↑connect 5C:F3:70connect 5C:F3:70:38:Act 5CE6 
wrong parameter count 

you can see the uart shows wrong what I copy on the uart

I copy it correctly but the Uart shows wrong

so I think if I can clean up the rx-tx in uart

or you know if there is any other problem

[ovrebekk]

Hi 

I just had a quick chat with the developer of the interactive example. Apparently there is no way to flush the buffers in this example because the UART functions are blocking. 

Whenever there is something to send the nrf_cli_process() function will run until the entire message is written to the UART, so you don't need to separately flush the buffers. 

Which terminal program are you using?

Have you tried with another one to see if the issue is the same?

Best regards
Torbjørn

[yu1998]

ovrebekk

yep First I use "putty" then I use "mobaXterm" Same problem still happened

now I use "sscom" still the same thing happened

I have tried three different terminal already

So I wonder if there is a way to clean up the RX/Tx or flow control at least

btw also I found out that if I send the message too fast the entire app will crash

For example:

If I press "tab" it will show all the commands which I can use

but as if I hold the tab and  not release the "tab" button

the uart will keep printing the commands which I can use

after n time printing the program will crash

is this a bug??

or if there is a way to clean up the RX/Tx or flow control at least

[ovrebekk]

Hi 

Can you give me a bit more details on what you want to use this example for?

This example is not designed to be used in a product. 

It is also in the experimental folder, which means we have only done limited testing on it. 
Possibly there are other examples that are more suitable for what you are trying to accomplish. 

Best regards
Torbjørn

[yu1998]

ovrebekk

unfortunately I am using it as a product on a unix system base

for this app Im trying to use this cli command to control N devices in ble 

find out it might be a bug in it can you guys tell me how to fix it  

actually we really need the cli command to control all of this

I mean even I change the size of

NRF_CLI_CMD_BUFF_SIZE

the bug still happened 

[ovrebekk]

Hi

I would strongly recommend considering another example if you are going to use this for a product. 

For instance, you can either run a standard Bluetooth HCI example on the nRF device, and run a standard Bluetooth host such as BlueZ on the Unix side. Then you will interface to the Bluetooth devices in a way that is common for other Unix applications. 

Alternatively, you can develop a custom application for the nRF device that controls the N devices, and provides an application specific interface between the nRF and the Unix host. 
The advantage of this method is that you can implement a more efficient, application specific command set between the nRF and the Unix host, but the drawback is that you need to do more application development on the nRF side. If you use the HCI example on the nRF you don't really have to do much development at all. 

If you think that using the ble_app_interactive example is the only option I can register an internal ticket to get help from the software team to improve the example, but I can not guarantee that this will be prioritized. 

Best regards
Torbjørn

[yu1998]

yea, after communicate with our project manager  they think that using the ble_app_interactive example is the only option" , so what should I do next

[ovrebekk]

Hi 

I will discuss the case with the CLI developer when he is back next week, and ask for some advice on how to proceed with this case. 

You should mention this issue to your local Nordic sales representative also, and he can help give this case priority. 

Best regards
Torbjørn

[Krzysztof Chruscinski]

The reason for artifacts in the UART CLI is that it doesn't use flow control so if you paste multple bytes some will get lost as receiver is being stopped and restarted after each byte. There are 2 options:

- enable flow control

- use different transport, namely UART which is using libuarte driver. Libuarte is a driver which allows continues reception on UART, receiver is never stopped and DMA buffers are seamlessly changed. For setting up libuarte transport see this example https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.0.2/cli_libuarte_example.html?cp=8_1_4_6_8.