Problem with UART watermarks

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

cross mob
lock attach
Attachments are accessible only for community members.
Anonymous
Not applicable

Arvinds,


I checked the thread: UART Routines  and the code you posted there.

I did 2 testes. In both tests I send 10 bytes to PUART when button is pressed (on TAG3 board):


#define W_MARK 0

void hello_sensor_interrupt_handler(UINT8 value)

{

    if (value&0x01)

  {

        // Set watermark

        // Max watermark level is P_UART_WATER_MARK_TX_LEVEL_HIGHEST ( = 15)

        P_UART_WATER_MARK_TX_LEVEL( W_MARK );

        if(P_UART_TX_FIFO_IS_EMPTY())

        {

              puart_synchronousWrite("12345678\n\r", 10) ;

              // Enable the TX interrupt. Callback registered with puart_txCb will be invoked when all bytes

              // have been transmitted.

              P_UART_INT_ENABLE |= P_UART_ISR_TX_FAE_MASK;

        }

    }

}

In puart_tx_callback function I check if TX FIFO is empty:


void puart_tx_callback(void)

{

    // Clear interrupt state

    P_UART_INT_CLEAR(P_UART_ISR_TX_FAE_MASK);

    // TX FIFO is empty now. So send another at most 16 bytes here if required,

    // set new watermark (if not 0) and re-enable TX interrupt.

    // check is TX FIFO is really empty

    if(P_UART_TX_FIFO_IS_EMPTY())

        ble_trace0(">>>>>> TX FIFO empty\n\r");

    else

        ble_trace0(">>>>>> TX FIFO not empty !!!\n\r");

}



Test 1.

#define W_MARK 0

puart_tx_callback reports that TX FIFO is NOT empty !!! why ????


Test 2.

#define W_MARK 15

Since we send only 10 bytes puart_tx_callback should never be called  (10 < 15)

In fact puart_tx_callback IS called !!! why ????

Attached, you will find the test code based on hello_sensor app.



0 Likes
1 Solution
Anonymous
Not applicable

Hello Lukasz,

Unfortunately, after speaking with the developers, only a workaround exists.

1.  For Test 1: If the FIFO is not empty in callback, busywait until it is empty.

2.  For Test 2: Unfortunately, we so not have a workaround.

Hope this helps.

Sincerely,

JT

kellyc vik86 madmax jasonc arvinds

View solution in original post

0 Likes
4 Replies
MichaelF_56
Moderator
Moderator
Moderator
250 sign-ins 25 comments on blog 10 comments on blog

We are looking into this internally.

madmax jasonrc vik86

0 Likes
Anonymous
Not applicable

Hello Madmax,

  I am pleased to see you post this as I was just getting ready to post a similar question.  I am interested to see the outcome of this as we are currently experiencing similar oddities with the PUART in which I understand from other sources they is an issue with the Water Mark setting in that it does not work as expected.  We are seeing significant amount of dropped bytes between the PUART and a MCU with anything larger than 128bytes at a time and ultimately it appears that the PUART interrupt handler is not getting serviced fast enough.  We have done a lot of testing with the Water Mark settings and they are not producing results as we would expect.

Regards,

Frank

0 Likes

This has been escalated to the business unit internally and we are attempting to allocate resources to look into the issue.

kellyc vik86 madmax jasonc arvinds

0 Likes
Anonymous
Not applicable

Hello Lukasz,

Unfortunately, after speaking with the developers, only a workaround exists.

1.  For Test 1: If the FIFO is not empty in callback, busywait until it is empty.

2.  For Test 2: Unfortunately, we so not have a workaround.

Hope this helps.

Sincerely,

JT

kellyc vik86 madmax jasonc arvinds

0 Likes