2 UARTs not working with gcc arm embedded

[ks73]

The following sample code does not work as expected when compiled with gcc arm embedded. Only the first UART (pc) outputs data as expected, there is no output on the second UART.

#include "mbed.h"

Serial pc(SERIAL_TX, SERIAL_RX);
Serial pc2(PA_9,PA_10);

int main()
{
    int cnt=0;

    pc.baud(115200);
    pc2.baud(115200);

    while (1)
    {
        pc.printf("UART PC : %d\n",cnt++);
        pc2.printf("UART PC2 : %d\n",cnt++);

        wait_ms(100);
    }
}

When stepping through the initialization of the serial objects I noticed that in the Stream.cpp constructor std::fopen only succeeds for the first call (that from Serial pc). The second instance (pc2) fails to initialitze because fopen returns 0, so that there are no correct function pointers in place for the subsequent calls to pc2.printf / putc.

I compiled this example also with the online compiler and it works correctly. The target ist STM32L053 Nucleo board.

[ciarmcom]

ARM Internal Ref: IOTMORF-309

[bcostm]

I have tested the above example on NUCLEO_L053R8 with the following to see if this issue is still valid:

• mbed IDE + mbed lib rev 139 --> OK
• compiled with uARM and mbed-cli --> OK
• compiled with ARM and mbed-cli --> Linking error due to not enough memory available
• compiled with GCC_ARM and mbed-cli --> FAIL. No printf on both USARTs. The program is still running (added a LED blink in the while loop)

So, yes this issue is still valid...
cc @jamike @LMESTM Any idea ?

Tested also with NUCLEO_L073RZ

• compiled with GCC_ARM and mbed-cli --> OK (in this case the GCC standard lib is used)
• compiled with GCC_ARM and mbed-cli + small lib (changed in targets.json) --> OK

[kegilbert]

Using a NUCLEO_L053R8 (MB1136 Rev C) and GCC I was successfully able to get both UART channels to work (see the attached image). The logic analyzer is decoding Serial1Tx (PB_9), while the putty window is receiving the USBTX serial stream.

Build and flash was done on an Ubuntu machine with GCC_ARM.

[LMESTM]

@kegilbert HI - thanks for sharing the info.
I think we're all aligned on this.
As @bcostm mentioned, this is working OK when building "mbed2" like program.
Nevertheless we can't have it work when compiling with mbed-cli, with below command
mbed compile -m NUCLEO_L053R8 -t GCC_ARM

can you share the build instructions you've used ?

@0xc0170 - any idea about the below changes behind using mbed5 vs mbed2 and would be related to printf ?

[LMESTM]

Some further findings:
If using RawSerial instead of Serial, the test is working fine.
With RawSerial, there is no dependency to the glibc and this works ok ... I gues this would do the job.
I'll continue to investigations a bit further

[LMESTM]

Here is what I see now:
In platform/Stream.cpp, during the 1st Serial object creation, everything goes just fine
but during the 2nd object creation, the call to
_file = std::fopen(buf, "w+");
returns a NULL file which is actually not checked in the function.

That would most probably explain why the later calls to pc2.printf() to not actually reach the serial port, because there is no registered file to actually map to it. The rootcause for fopen to fail seems to be a memory restriction as I have checked the errno and it is positioned to ENOMEM.

@ks73
My conclusions for now:

1. I would recommend to use RawSerial for the demanded use case as it requires much less memory and will work fine even on small targets
2. to mbed team, I would recommend adding a check on the _file handle in the Stream creator to raise an error - @0xc0170 what do you think ?

[0xc0170]

to mbed team, I would recommend adding a check on the _file handle in the Stream creator to raise an error - @0xc0170 what do you think ?

+1 for adding a check.

Why does it fail? Not enough memory thus it fails via allocating new space on the heap ?

[LMESTM]

Ok I'll try to add a check. about error, I checked ENOMEM was the error but I haven't checked the details behind.

[LMESTM]

@ks73 @0xc0170 @sg- #920 has been closed and #4259 has been merged - I think this ticket should be closed as well