9 years, 10 months ago.

Nucleo F411RE USART2 stops sending under certain conditions

I've encountered a problem with USART2 on the STM32F411RE processor. I have a simple serial passthrough program that allows bi-directional data flow through the processor

    // USART2
    Serial usb(USBTX, USBRX);
    // USART1
    Serial ext(D8, D2);
    while (true) {
    if (usb.readable())
        ext.putc(usb.getc());
    if (ext.readable())
        usb.putc(ext.getc());
    }

I've been building against revision 06e2b3c8802cb4f78e9958ba9923755bd458e8b7 of the master branch of https://github.com/mbedmicro/mbed. I've done my testing with GCC ARM Embedded, but I've duplicated some tests with IAR to make sure the issue wasn't related to the GCC ARM Embedded toolchain.

I've been reproducing this issue by streaming a 100kB text file through the device. I have a python script that sends the file into a serial port on my PC and another script that reads the other serial port into a file on my PC. Both serial ports are (obviously) connected to USARTs on the Nucleo. I then compare the original and received file.

What I see is the following:

• When the data is sent in USART1 and out USART2:
  • At bauds <= 38400, all data makes it through to the other side.
  • At bauds > 38400 (up to 230400), only the first 2-5kB of data make it to the other side.
• When the data is sent in USART2 and out USART1 or USART6:
  • All the data makes it through at any baud rate.

I have established that the entire processor isn't locking up by setting up a Ticker object with a callback that blinks LED1 on the Nucleo. Even after my serial data stops, the LED keeps blinking indefinitely.

I'm always hesitant to point fingers at hardware too early, but I'm not sure what else to think at the moment. Anybody have any suggestions? I'm happy to share complete binaries/code/scripts I'm using in the testing process if anybody wants to take a look for themselves.

-Mike