CC2340R5: UART read every 100ms fails

Hello Vignesh,

I hope you are doing well! I wanted to ask if we could try the code in an empty, or UART example project (rather than BLE) to see if we still notice the issue. It does sound odd that changing the interval would change the amount of received packets.

Also could we add a return newline to the following? (should be "...matching\r\n")

UART2_write(uart,"Receive data not maching",24,0);

Thanks,
Alex F

Hi Alex,

I have tried with an UART callback example project. There I didn't face any issue.

Buffer Allocation:

Application UART_MAX_READ_SIZE = 100;

 In SYS.config(Default) UART RX Ring Buffer Size = 32;

Then I have cross checked the UART configuration between UART Callback Example Project and Application Project(Basic BLE Project with UART Over Run issue fixed).

When we started analyzing the code we found that UART RX FIFO is not clearing, so first we tried UART2_readCancel(uart); then UART2_flushRx(uart); 

before next UART2_read(uart, uartReadBuffer, UART_MAX_READ_SIZE, 0);. even then UART RX FIFO is not Clearing.

When we are check the UART Data Size form the UART Callback, we getting double size from the actual packet size, when the data reception delay of 100ms.

Buffer Allocation:

Application UART_MAX_READ_SIZE = 300;

 In SYS.config UART RX Ring Buffer Size = 1500; Recommend by TI support Team, For your reference attached an link below.

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/1345246/cc2340r5-uart-overrun-event-has-occurring

Thanks,

Vignesh.

Hello Vignesh,

I have used the flush command in the past to the same effect, also paired with a memset of the buffer:

void clear()
{
    memset(buffer, 0, strlen(buffer));
    memset(input, 0, strlen(input));
    UART2_flushRx(uart);
}

Clement's recommendations in that thread should also be a good reference!

Thanks,
Alex F

Hi Alex,

     We have tired UART2_flushRx(uart); even then in uart callback we are getting count as 200 or 300.

For Example:

Every 100ms we are transmitting 100 bytes of data (In UART packet first bytes contains length(0x64)) to UART, but in UART Callback we are getting count as 200 or 300 after multi transmitting.

kindly provide us how to clear the UART Ring Buffer.

Thanks,

Vignesh.

Hi Vignesh,

Can you give me the list of changes to implement in the basic_ble example to reproduce the same? Please make sure to specify all the changes made in the SysConfig.

Regards,

Hi Clement,

      Sorry, I won't be able to share source code on forum.

Thanks,

Vignesh.

Hi Vignesh,

Please share the minimal code changes to reproduce the issue on the basic_ble example - no need to share you whole source code.

Best regards,

We have sent the source code separately via email.

Hi Rahul,

Thank you.

I have completed an initial review of your code (but I haven't yet manage to build and test it).

I have identified a scenario that may lead to the issue you described - As your system is running quite a complex program, the core may not service in time some of the UART callback. As a consequence you may enter the callback after receiving not one, but two or three 100-byte buffers.

In order to check if this scenario is happening, you could toggle a pin every time you enter the UART callback. Then using a logic analyzer, you can record the UART traffic and the activity on the pin.

Assuming the scenario described occurs, I would recommend to accept the behavior - i.e. check the number of bytes in the buffer and, if there is more than one UART message, ensure to handle all the messages.
To actually fix the issue, you would have to increase the priority of the UART handling - but this would actually have quite some side effects on the BLEStack (so I am not recommending to pursue this path).

Please let me know your thoughts.

Best regards,

Hi Clement,

   I have checked the scenario by toggle a pin every time when it entering into the UART callback. Then using DSO we measured the signal there we found the timing is not same across all the UART callbacks.( Some UART callbacks are100ms,when the error occurs it will be around 250ms to 350ms Approx. ).

And we tried disabling the  BLEAppUtil_invokeFunction(HandlingFunction, NULL); in the UART callback routine we are able to see the signal as expected. (like every 100ms GPIO is toggling).

Could you suggest is there any other ways to handle the callback function for process the data. 

Thanks,

Vignesh.

Hi,

Your observations confirm the scenario I have mentioned.

As you have noticed, unless you make large changes in the software design, you won't manage to have the callback as desired.

The approach I suggest is then to check the length of the buffer passed within each callback. Based on the length you can assess the number of messages you have. You should then be able to adapt the data handling.

I hope this will help,

Best regards,

Hi Clement,

Thanks for your response.

Clément said:

As you have noticed, unless you make large changes in the software design, you won't manage to have the callback as desired.

The changes has to done on our application or stack side.

Clément said:

The approach I suggest is then to check the length of the buffer passed within each callback. Based on the length you can assess the number of messages you have. You should then be able to adapt the data handling.

With a current UART implementation has DMA enabled? and how can we use it like configuring the DMA buffer size. If it possible can you provide us the UART DMA example source code.

Another issue where we are facing when trying to send data from module to mobile  continuously with the size of MTU excahnged size 247(mtu_value) after multiple packets transmission from the module we are getting an status as blePending.

After this error occurs we are not able to connect or pair with the module and module requires an power restart to recover.

Status =  SimpleGattProfile_setParameter(SIMPLEGATTPROFILE_CHAR4, mtu_value,&uartReadBuffer[SentDataLen]); 

Kindly help us to resolve the issues.

Thanks,

Vignesh.

Hi Vignesh,

Have you managed to implement the suggestion I made in my previous message?

Clément said:

The approach I suggest is then to check the length of the buffer passed within each callback. Based on the length you can assess the number of messages you have. You should then be able to adapt the data handling.

To answer your question "The changes has to done on our application or stack side", the changes suggested have to be made at the application level.

For the issue below, could you please confirm you are using SDK 8.10.01.02 - this issue looks like one that got fixed in this SDK?
If yes, I would recommend to open a dedicated thread so we avoid mixing topics.

vignesh s said:

Another issue where we are facing when trying to send data from module to mobile  continuously with the size of MTU excahnged size 247(mtu_value) after multiple packets transmission from the module we are getting an status as blePending.

After this error occurs we are not able to connect or pair with the module and module requires an power restart to recover.

Status =  SimpleGattProfile_setParameter(SIMPLEGATTPROFILE_CHAR4, mtu_value,&uartReadBuffer[SentDataLen]);

If you are already using SDK 8.10.01.02, can you please specify the interval you are calling SimpleGattProfile_setParameter() with? What is the connection interval you are using?

Regards,