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

  • You have the first revision of the nRF51 chip and this only had receive buffers of 2 bytes. This was increased to 6 bytes in the second revision (QFAAG0) of the chip. It sounds to me like you are pushing/receiving data faster than what you are able to read out of the receive buffer and hence it goes full and it falls apart. Do you have a kit with the second revision of the chip available? I would recommend you to try your code on a kit with QFAAG0.

    Link to Product change notification regarding increase from 2 to 6 bytes of receiver buffer.

  • Hi Asbjørn,

    Thank you for quick reply.

    We've replaced chip to QFAAG0 and I'm now going to run long term test at 921600 bps (still without hardware flow control) though.

    Regarding the first revision chips, I understand that these have only 2 bytes buffers but I'd thought that a byte should be simply overwritten in that buffer so transmission is corrupted (and this happens quite frequently). I don't understand however how it is possible that the the fifo fails completely and that it fails only for the transmission from NRF51 chip. The reception interrupts still occurs even though the code locks up in the fputc function.

    Can you give me any hint regarding this, please?

    Update 18/10/14:

    I've caught the lock up in the debugger, this is what have so far:

    • m_current_state is set to UART_ON however the EVENTS_TXDRDY interrupt doesn't occur, due to that state doesn't change to UART_READY, the software fifo fills up and lock up occurs.
    • NRF_UART0->TASKS_STARTTX = 0
    • NRF_UART0->TASKS_STOPTX = 0

    Many thanks, Krzysztof Rosinski

  • 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.

  • Asbjørn,

    Just to confirm, the same issue occurs on the QFAAG0 chip,- it has locked up 18 times overnight at 921600 bps, the test duration was around 16 hours so I think it's roughly the same as for the first revision chip (it locks up around every 40 minutes for the first revision). In the same time I've been testing this at 460800 bps (first revision chip) without any problem.

  • It sounds like it repeats itself at fairly constant time intervals. Do you miss any RXDRDY events from the UART similar to what @John is stating below here? Are you checking the received data and possibly the order of it?

    Are you using the UART alongside using a BLE softdevice?

    The lock up in app_uart_put() seems to indicate the the app_uart_states is not UART_READY. Are you able to read out which state the uart is is when it locks up?

Related