Problems using UART

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Anonymous
Not applicable

I had problems using a 115200 baud UART on different states of the BLE Stack Event Handler. I have debug messages in every state and in some state I need to send some info over the UART. Sometimes when I write about 10-15 bytes, one character sent is changed by another one. Making a step by step debugging I can see that there's not corrupted memory. Also I know that it's not noise over the tx line of the UART. This issue is fixed adding a 1ms delay on the main infinite loop. Any idea of what is the cause of this behaviour and why this delay fixes it?

   

Thanks in advance.

0 Likes
1 Solution
Anonymous
Not applicable

Try the following line of code before you use any API calls that affect flash storage (such as creating a bond):

   

        while ((SCB_SpiUartGetTxBufferSize() + SCB_GET_TX_FIFO_SR_VALID) != 0u) { }

   

Note, you may need to modify the "SCB_" prefix to match the name of your SCB UART component, if it is something besides "SCB" in your design. This code will wait until all outgoing transmissions are complete before proceeding.

View solution in original post

0 Likes
5 Replies
Bob_Marlowe
Level 10
Level 10
First like given 50 questions asked 10 questions asked

When the project goes to deep sleep, a running UART will get its data corrupted. Best practice will be to wait until the transfer is completed.

   

 

   

Bob

0 Likes
Anonymous
Not applicable

Hi Bob,

   

thanks for your quick reply. I don't use deep sleep. The project just does an advertisement and connects to a remote client when a client requests for it (the project is a peripheral server).

   

Thanks again.

0 Likes
Anonymous
Not applicable

Are you using a part with 128K of flash, and if so, what is the main CPU clock set to? Certain operations within the BLE stack (particularly flash-related operations such as bonding) will cause the CPU clock to change to 48 MHz on 128K parts for the duration of the operation. Changing the main clock to 48 MHz should stop this if it is the culprit, although this will come at the expense of higher power consumption.

   

256K parts don't have this side effect with flash operations.

   

It might be helpful to know which debug output calls exhibit the byte corruption, and what operation(s) they are immediately followed by.

0 Likes
Anonymous
Not applicable

Hi jrow,

   

yes, I'm using a CY8C4247LQI-BL493 part and I'm using the flash because I manage bonding data, but I'm already using the CPU at 48MHz. It usually happens when I make unbondings and removing devices from white list.  I also have to send a "disconnect" flag through UART and thats when it happens. But sometimes it also happens when I use debug messages in every state of the stack event handler. I'll try to make some (more) tests to enclose the issue.

   

Thank you very much.

0 Likes
Anonymous
Not applicable

Try the following line of code before you use any API calls that affect flash storage (such as creating a bond):

   

        while ((SCB_SpiUartGetTxBufferSize() + SCB_GET_TX_FIFO_SR_VALID) != 0u) { }

   

Note, you may need to modify the "SCB_" prefix to match the name of your SCB UART component, if it is something besides "SCB" in your design. This code will wait until all outgoing transmissions are complete before proceeding.

0 Likes