This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

[NRF51] UART lock up at 921600 bps

Hi,

We have an issue with app_uart_fifo which occasionally locks up during data transfer from NRF51 to an other uC.

System description:

We're using first revision chip (QFAAC0) and the UART don't use hardware flow control (PCB is ready without CTS & RTS connected).

We have transmission from other uC to NRF51 (around 60 B/s), which causes missing bytes problem. That's why we've decided to increase baud rate to the highest possible rate in order to lower down missing bytes within each packet. We still have corrupted packets but number of these much less than for 115200 bps which we've used before.

Problem description: Unfortunately, as soon as we've increased baud rate to 921600, very rare lock ups have started to occur. It seems that the lock up occurs more often when more data is transfered from NRF51, e.g. when we transfer around 4500 B/s issue occurs around every 40 minutes and for around 600 B/s lock up occurs roughly every 5 hours period.

I've been testing the same source code with 460800 bps and everyting seems to be working fine (14 hours test).

The source locks up in the fputc function:

int fputc(int ch, FILE * p_file) 
{
    while(app_uart_put((uint8_t)ch) != NRF_SUCCESS)
        ;
    return ch;
}

The tx fifo is full so the function locks up as it's not possible to add any byte to the fifo and int the same time the transmission interrupt doesn't occur. The debugger doesn't break in the following source code:

    // Handle transmission.
if (NRF_UART0->EVENTS_TXDRDY != 0)
{
    // Clear UART TX event flag.
    NRF_UART0->EVENTS_TXDRDY = 0;
    on_uart_event(ON_TX_READY);
}

Do you have any hint what could cause such issue, please? Let me know if I could provide some more information from the debugger which can help with investigation.

Kind Regards, Krzysztof Rosinski

Parents
  • I had a similar lockup problem with the UART in the early stage of my project. It turned out I was clearing NRF_UART0->EVENTS_RXDRDY after reading the character out of the RXD register. This opened a very small window where another character could be added to the RXD register before I cleared NRF_UART0->EVENTS_RXDRDY. So when I did clear NRF_UART0->EVENTS_RXDRDY I was clearing the event for the second character. Simple solution was to clear NRF_UART0->EVENTS_RXDRDY before reading the character out of RXD. The faster the UART baud rate the more likely you are to see this problem I think.

Reply
  • I had a similar lockup problem with the UART in the early stage of my project. It turned out I was clearing NRF_UART0->EVENTS_RXDRDY after reading the character out of the RXD register. This opened a very small window where another character could be added to the RXD register before I cleared NRF_UART0->EVENTS_RXDRDY. So when I did clear NRF_UART0->EVENTS_RXDRDY I was clearing the event for the second character. Simple solution was to clear NRF_UART0->EVENTS_RXDRDY before reading the character out of RXD. The faster the UART baud rate the more likely you are to see this problem I think.

Children
No Data
Related