Inconsistent UART receive problem

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

cross mob
Anonymous
Not applicable

Hi,

We have Discover Wi-Fi SN8200X module eval board from Element14 and WICED SDK-2.4.0 patched with SN8200x patch in Linux.

We are using UART to communicate with an external device (Baud - 9600, Parity - even, 1 stop bit,  Flow control disabled). The board sends command and device responds with requested bytes. This happens fine initially.

But after some random time (may be 10 mins, 1 hr, 4 hrs or never - Very inconsistent), we observe that the wiced_uart_receive_bytes() function fails (returns WICED_ERROR).  Through CRO we can see that UART is actually seeing the bytes at its input lines.

We are not using ring buffer in code (optional_ring_buffer is NULL) to receive bytes.

Once the above stated problem happens, we had to reset the board to make it working (but soft reset does not work).

When we saw the definition of wiced_uart_receive_bytes() function, we found that when not using ring buffer, the wiced_uart_receive_bytes() function calls platform_uart_receive_bytes() function which always returns WICED_SUCCESS in definition.

But we are facing  WICED_ERROR from the function after sometime. How this happens ? Are we missing something? Please help in this regard.

Thanks in advance.

0 Likes
15 Replies
GregG_16
Employee
Employee
50 sign-ins 25 sign-ins 25 comments on KBA

Raghuraman S

Do you have any additional details?

We will look into this if it is still an issue for you.

0 Likes
Anonymous
Not applicable

Yes I still have this problem.

I also used the platform_uart_receive_bytes() function directly as I am not using ring buffer.

The function fails to receive bytes after an arbitrary amount of time. So far It worked continuously for a maximum of 5 days. After that the function failed to receive. I am sure of the incoming bytes as I am able to see them in CRO.

Are there any more details that I need to give ?

0 Likes

We will look into this, let us follow up.

Evan Hunter

0 Likes
Anonymous
Not applicable

Your problem is in platform_uart_receive_bytes().   It sets uart_interfaces[uart].rx_dma_result to WICED_ERROR before starting the DMA. Normally a DMA interrupt (usartX_tx_dma_irq) occurs before the timeout and sets the value to WICED_SUCCESS, then posts a semaphore on which your thread is waiting.

Another way this can happen is in the interrupt function, if a DMA error has occurred then WICED_ERROR will be returned.

On your system one of the following things is probably happening:

  • the interrupt is not occurring - try adding a global counters to the platform_uart_receive_bytes() function and to the usart1_tx_dma_irq() (assuming you are using UART1)  and check if they match.  This could be because:
    • The interrupt has been disabled in the NVIC
    • The interrupt has been disabled in the DMA engine
    • The DMA engine got disabled and did not complete
    • The GPIO pin functions got changed
    • The UART got disabled

     I suggest you check all the hardware registers for these items to determine if they are all still ok

  • The DMA engine detected a:
    • Transfer Error due to a memory bus write error
    • Fifo error due to underrun, overrun etc
    • Direct mode Error - See STM32 manual

     I suggest you set a global variable when usart1_tx_dma_irq() sets WICED_ERROR to see if this is occurring

Regards,

Evan

Anonymous
Not applicable

Hi,

Thanks for the suggestions. I will try to do this. Is this solved in SDK-2.4.1 ?

0 Likes
Anonymous
Not applicable

Hi, Any updates in this issue ?

0 Likes
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Hi,

I have attached a log of "to & fro" data and global variables for usart1_tx_dma_irq(), usart1_rx_dma_irq(),  usart1_irq().

This log doesn't contain the UART problem. We are running the system and I will post more logs once I encounter one.


This is just for clarification of the flow.

It seems that only usart1_tx_dma_irq() gets called during each UART poll and usart1_rx_dma_irq() remains silent. Can you explain why the usart1_rx_dma_irq() is not getting called though both Tx and Rx happens in UART ?

Thanks in Advance.

0 Likes

Hi,

Do you still have an issue with UART interfce?

Thanks,

Seyhan

0 Likes
Anonymous
Not applicable

Hi Seyhan

Yes . I still have this issue .

0 Likes
Anonymous
Not applicable

Dear Raghu

Can you please update your mobile number, so that we'll discuss and get more details on this issue? I believe this board uses STM32F2 ARMCM3 core, please correct me if I'm wrong. Also you face the issue on both DMA and Ringbuffer specific issues,

As Seyhan mentioned, we don’t reproduce this issue /w our boards, so we'd like to know the application and amount of bytes data transfer and the details of use case and more of setup details

If you could share your mobile number, then we'll discuss with you in detail and update

Siva

0 Likes
Anonymous
Not applicable

Hi,

Thanks for the reply. Our board (Murata SN8200) has ARMCM3 core but STM32F10x. I will message you my mobile number.

Thanks.

0 Likes

Hi raghu,

             Is there any update on the issue.

Teja.

0 Likes
Anonymous
Not applicable

Hi Teja,

Our device with which SN8200 board communicates through UART has a maximum baud rate of 19200. So we are not able to use the specified baud rate (115200).

Presently we have made some changes in our code such as changing default mode of the board to receiving mode (previously it was in transmitting mode by default between polls), etc. We are testing with the code changes. We will update you with the result soon.

Thanks

0 Likes

Hi,

If the FTDI chip serial port to baud rate needs to be changed to 19200 update below in the platform files. For STM32F2xx platform this is the file, Wiced/Platform/common/ARM_Cortex_M3/STM32F2xx/stm32f2xx_platform.c. Other platforms have their own files in respective locations.

static const wiced_uart_config_t stdio_uart_config =

{

    .baud_rate    = 19200,

    .data_width  = DATA_WIDTH_8BIT,

    .parity      = NO_PARITY,

    .stop_bits    = STOP_BITS_1,

    .flow_control = FLOW_CONTROL_DISABLED,

};

You may also setup other UARTS to send and receive data over the serial interface with your own setup. Here is a sample app UART Setup and Uart Messages Over Webpage. For seting up WICED_UART_2 define USE_UART2_AS_SERIAL_PORT at uart_rxtx.c. You may change the baudrate as follows in the same file.

wiced_uart_config_t uart_config =

{

    .baud_rate    = 19200,

    .data_width   = DATA_WIDTH_8BIT,

    .parity       = NO_PARITY,

    .stop_bits    = STOP_BITS_1,

    .flow_control = FLOW_CONTROL_DISABLED,

};

Thanks,

Seyhan

0 Likes
manit_56
Employee
Employee
First like received

Hi,

This is my observation about the issue.

Baud rate

Stm32f1x

Stm32f2x

Ring Buffer  and dma enabled (size in bytes)

result

115200

  na

yes

64

Over night tested, No issues found

9600

na

Yes

64

Found Data loss

9600

na

Yes

512

Found Data loss

We found that there was a timing issue. We used “realterm application” (this is free software)

Here is our observation

  • - With baud rate-115200, ring buffer(64 bytes) + DMA.  No data loss found  (pumped nearly 120MB data)
  • - With baud rate-9600, ring buffer(64 bytes) + DMA. Found the data loss. If we are increasing the buffer size(of ring buffer) , found less data loss. If maintained delay between character transmission (2-4ms). Found no data loss(Pumped nearly 1Lakh bytes).
  • - With 9600 baud, without ring buffer, maintaining delay while pumping data(transmitting). With 3-5ms delay between character found no data loss(pumped nearly 1Lakh bytes).

Thanks,

Teja.