Buffered STDIN/STDOUT crashes on RTL8195AM and Ublox ODIN W2

[SeppoTakalo]

Description

When sending bytes bidirectionally to Uart that handles STDIN/STDOUT the Realtek 8195 seems to crash.
This is basically same issue that was reported in #6358 but requires faster speed than what humans can type.

To reproduce:

mbed new serial-test
cd serial-test
cd mbed-os
git checkout master
cd ..

Then create main.cpp and mbed_app.json as follows:

main.cpp

#include "mbed.h"

int main() {
    printf("Started!\r\n");

    while (true) {
        int c = getchar();
        if (c != EOF) {
            printf("Input: %c\r\n", c);
        } else {
            return 0;
        }
    }
}

mbed_app.json

{
    "target_overrides": {
        "*": {
            "platform.stdio-buffered-serial": true
        }
    }
}

Now compile and run the program.

It first seems to work, if you type in anything. But if you copy&paste some string that is longer that 10 characters, then it crashes.

So for example, paste following to the serial terminal: 0123456789A
Output would be:

Started!
Input: 0
Input: 1
Input: 2
Input: 3
Input: 4
Input: 5
Input: 6
Input: 7

And then it does not respond anymore

Note: If you set stdio-buffered-serial to false it does not crash.

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug

[SeppoTakalo]

Just verified that Ublox EVK ODIN W2 also crashes somehow if baud rate is set to 115200 and paste a bit longer text:
0123456789A0123456789A0123456789A0123456789A0123456789A0123456789A0123456789A0123456789A0123456789A

So for Ublox EVK ODIN W2 use following mbed_app.json

{
    "target_overrides": {
        "*": {
            "platform.stdio-buffered-serial": true,
            "platform.stdio-baud-rate": 115200
        }
    }
}

[Mirrored to Jira]

[SeppoTakalo]

Verified that does not crash on K66F
[Mirrored to Jira]

[samchuarm]

adding @ARMmbed/team-realtek @M-ichae-l , Hi Michael, please help look into this STDIN/STDOUT crash and address it for RTL8195AM. Thanks.
[Mirrored to Jira]

[samchuarm]

Adding @AdamZhang0124
[Mirrored to Jira]

[adbridge]

Internal Jira reference: https://jira.arm.com/browse/IOTPART-6510

[jenia81]

This issue also affects SDA (secure device access) project that runs on Sales Demo Device (WEM device, modification of Ublox Odin W2). When running SDA example application with Serial it crashes from time to time. @TaniaMirzin, can provide more details if needed

[samchuarm]

@M-ichae-l , can you please verify this STDIN/STDOUT crash for RTL8195AM?

[M-ichae-l]

@SeppoTakalo
I have followed your process. However, I am not able to produce the error with all three compilers (GCC, ARM, and IAR). My side the UART is working perfectly. Could you please check again? Thank you.

[samchuarm]

Hi @SeppoTakalo , as we can't reproduce the crash, can you help comment on the reproduce steps? Thanks

[SeppoTakalo]

=========================================================

ROM Version: 0.3

Build ToolChain Version: gcc version 4.8.3 (Realtek ASDK-4.8.3p1 Build 2003) 

=========================================================
Check boot type form eFuse                                                             
SPI Initial                                                                            
Image1 length: 0x4398, Image Addr: 0x10000bc8                                          
Image1 Validate OK, Going jump to Image1                                               
SDR Controller Init                                                                    
Started!
=========================================================

ROM Version: 0.3

Build ToolChain Version: gcc version 4.8.3 (Realtek ASDK-4.8.3p1 Build 2003) 

=========================================================
Check boot type form eFuse
SPI Initial
Image1 length: 0x4398, Image Addr: 0x10000bc8
Image1 Validate OK, Going jump to Image1
SDR Controller Init
Started!
Input: 0
Input: 1
Input: 2
Input: 3
Input: 4
Input: 5
Input: 6
Input: 7

Crash same way as previously.
How can you not reproduce this issue. Do we have different HW revisions, or different compiler?

arm-none-eabi-gcc (GNU Tools for ARM Embedded Processors 6-2017-q2-update) 6.3.1 20170620 (release)

Are you entering the characters by hand or copy&pasting?
Because if you enter slowly enough, it does not crash.

[M-ichae-l]

@SeppoTakalo

I have followed your process.

Where did you put the main.cpp and mbed_app.json ?
I put them under mbed-os folder.

[SeppoTakalo]

As normal application, not inside of mbed-os.

See the first message.

mbed new serial-test
cd serial-test

Now create those files.

Then we can checkout mbed-os master

cd mbed-os
git checkout master
cd ..

[tung7970]

@M-ichae-l Can you share your binary file for @SeppoTakalo to try ?
@SeppoTakalo Can you do the same too ?

[M-ichae-l]

@SeppoTakalo I am now able to produce the error. I am working on it.
@tung7970 thank you for the suggestion.

[samchuarm]

Hi @M-ichae-l , any update on this? Thanks.

[M-ichae-l]

@samchuarm still processing.
The device hangs once the data more than 7 for example "0123456" is the max passed data. I wonder if it is a FIFO issue.

[samchuarm]

Hi @M-ichae-l , has there been any progress on this issue? Thanks.

[samchuarm]

Hi @M-ichae-l , any update on this?

[M-ichae-l]

@samchuarm it is still under processing.

[samchuarm]

Hi @M-ichae-l , is there any way we can get this issue progressed? Thanks.

[samchuarm]

Hi @M-ichae-l , any update on this?

[M-ichae-l]

Hi, @samchuarm
I am not working on this issue right now. I will continue working on this issue when I have done others.

[samchuarm]

Hi @ARMmbed/team-realtek , this has been open for months. Could we get the issue progressed and fixed? Thanks.

[AdamZhang0124]

Hi @samchuarm ,
I have been assigned to solve this problem. I have checked and tested our SDK, the logUART TX RX function is running fine without aforementioned 'crash' problem.
I speculate that the problem may relate to rx_irq or tx_irq, maybe somewhere blocks the interrupts from triggering after too many characters received concurrently.
I am still investigate the root cause now and I will let you know the results, thanks.

[AdamZhang0124]

Hi @samchuarm ,
Good news! The root cause of this issue has been spotted and fixed. Now we are checking if the solution would affect other functions. The release of the solution can be expected soon.

[AdamZhang0124]

Hi @SeppoTakalo and @samchuarm ,

The fix for this issue has been committed with the PR of #9923. Please help to review it. Thanks!

[samchuarm]

Adam, thanks for your effort fixing the issue.

Hi @SeppoTakalo , since the PR# #9923 has been approved, can this issue be closed now? Thanks.