Nucleo F411RE USART2 stops sending under certain conditions

[mfiore02]

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 06e2b3c of the master branch. 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

[sg-]

I've noted similar behavior on multiple platforms and it seems to do with Stream as a base class. Can you try to create RawSerial objects instead of Serial?

Here is a similar test harness that exhibits the problem. http://developer.mbed.org/users/sam_grove/code/data_loss_test/

[mfiore02]

I forgot to mention that I tried RawSerial objects in my test setup and got the same results as Serial objects.

[ciarmcom]

ARM Internal Ref: IOTMORF-290

[LMESTM]

@mfiore02
I've run the test on mbed master head today.

With Serial objects I can indeed encounter the issue when running @ 115200kbps.
On the other hand, this is working fine with RawSerial, in both directions.

I have checked the reason behind and we're reaching the limits of processing in the main loop when increasing the baudrate, i.e. 2 consecutive char will be received on 1 serial while the other one is being checked. Using the RawSerial is more effective so this is pushing the limit, but increasing the baudrate further would end up in the same situation sooner or later.

When reaching the limit, serial IP faces an overflow error (UART_FLAG_ORE) and will not be readable until this flag is cleared. I made a dirty patch that clears the flag in calls to serial_readable, then the next characters can be received again, but characters have been lost anyway, so I'm not sure this is what we want.

@sg- @0xc0170
I'm not sure how to inform MBED application about this overflow error on Serial port, any advice on this ?

About the asymmetric behavior USART2 vs. USART1 & 6, this is most probably related to the buses frequencies. UART1 & 6 are on APB2 while USART2 is on APB1 and the frequencies differ, so the performance limit will vary as well.
*-----------------------------------------------------------------------------

• APB1CLK (MHz) | 48 | 48
  *-----------------------------------------------------------------------------
• APB2CLK (MHz) | 96 | 96
  *-----------------------------------------------------------------------------

[mfiore02]

@LMESTM I've already made a PR to do what you mentioned as a fix for #1605. See #1608.

That fix was specifically for STM32F4 devices. @sg- have you seen this issue on just ST platforms or others too? Do we need a broader fix?

[LMESTM]

@mfiore02 - thanks for the link. From what I've seen your PRs apply in IRQ based communication, which makes more sense I think that polling in the main loop !
But I'm not sure you fix will get in action with the example provided in this issue because it is based on polling .. not sure if this is worth looking for a solution though because the design of polling the 2 uarts in the loop does not look efficient.

So let us know if you think we can close this issue or not

[mfiore02]

@LMESTM True, polling is far from efficient. I agree with your reasoning - the difference in APB speeds does explain the issue.

I think the "dirty patch" may be worthwhile even if it's not a perfect solution. It seems to me that losing some data is better than getting stuck indefinitely.

[LMESTM]

@mfiore02 - Ok then let's look for a fix. the fix I tried was checks the error flags at every call to _readable() and erase any found error. This would decrease performances further and not even inform application of encountrered error.

I think a proper fix would imply a way to inform the running application that there was an error. so back to the question @sg- @0xc0170 Any idea how to do this ? As of now, readable() doesn't allow application to manage error cases.

[LMESTM]

@sg- @0xc0170 please provide guidance here: what shall be do in case a serial read fails ? (because of performances limits that are reached, so overflow condition is met )

[0xc0170]

@sg- @0xc0170 please provide guidance here: what shall be do in case a serial read fails ? (because of performances limits that are reached, so overflow condition is met )

As you wrote earlier, handle errors so it wont affect the application. To report them, we will need to extend API. There was an addition for this in mbed 3, we will consider this.

cc @c1728p9

[c1728p9]

I have a feature branch with this API extension here (Initially proposed in #2566):
https://github.com/ARMmbed/mbed-os/compare/serial_error_interrupt

[LMESTM]

@0xc0170
I just made a quick test with managing errors in the driver thanks to #4502
I used 460800 baudrate with the basic application provided in example of this issue, and for sure the target can't cope with this rate from a simlpe polling loop and Stream based Serial objects.
So, with the fix, indeed the application is still alive - but I can't understand how this won't affect application, because I suppose that application probably needs to receive proper data to work properly.
Let me know if you think this makes sense anyway - PR is there

[LMESTM]

ST_TO_BE_CLOSED

[LMESTM]

@0xc0170 @mfiore02
#4502 has been merged - could you closed the issue ?

[bcostm]

@0xc0170 can you please close it ?