Run-time error when defining multiple Serial objects

[amitchone]

Description of defect

I am working on a project that requires 2 UARTs, one µC<->PC and the other µC<->SARA N211.

Initially, when trying to create two Serial objects as below, the following Fatal Run-time error is produced:

Serial pc(PA_2, PA_3, 9600);
Serial modem(PB_6, PB_7, 9600);

- ++ MbedOS Error Info ++
- Error Status: 0x80FF0100 Code: 256 Module: 255
- Error Message: Fatal Run-time error
- Location: 0x8008781
- Error Value: 0x0
- Current Thread: main  Id: 0x20001CCC Entry: 0x8007241 StackSize: 0x1000 StackMem: 
0x200006D0 SP: 0x200015D4 
- For more info, visit: https://mbed.com/s/error?error=0x80FF0100&tgt=MTB_MURATA_ABZ
- -- MbedOS Error Info --
- Error: new serial object is using same UART as STDIO

I believe that this Run-time error is due to both PB_6/PB_7 and the default STDIO UART pins (PA_9/PA_10) sharing the same hardware peripheral - USART1.

At this point I attempted to override the default STDIO UART pins to pins that used a completely separate hardware peripheral. I tried using PA_0/PA_1 (USART4) and PB_3/PB_4 (USART5). When doing this, we no longer see the Run-time error but, when monitoring either the PC or N211 UART, no output is observed and current consumption of the device increases to ~50mA from ~10mA. It should be noted that the program is running as, if I attempt to periodically send a UART message and attempt to toggle another GPIO pin at the same time (connected to a buzzer) the buzzer beeps at the specified period.

I should confirm that, without overriding the default STDIO UART pins I am able to have a simple UART echo program on my PC UART operating just fine (returning what I type and current consumption as expected), see below:

#include <mbed>

Serial pc(PA_2, PA_3, 9600);

int main() 
{
    while(true)
    {
        if(pc.readable())
        {
            pc.putc(pc.getc());
        }
    }
}

I am using a custom board but have triple-checked the pinout of the processor and footprint (and had this sanity checked by other, real-life, people and all seems to be in check,

Target(s) affected by this defect ?

TARGET_MTB_MURATA_ABZ
Note that I initially discovered this issue whilst using the MTB_MURATA_ABZ as the target but using an STM32L083KZ processor.

I have also verified that the Run-time error issue exists when using a genuine MURATA_ABZ module.

Toolchain(s) (name and version) displaying this defect ?

ARM Compiler v6.11

What version of Mbed-os are you using (tag or sha) ?

5.14.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

Clangd 8.0.0

How is this defect reproduced ?

The Run-time error is reproduced as follows:

#include "mbed.h"

Serial pc(PA_2, PA_3, 9600);
Serial modem(PB_6, PB_7, 9600);

int main()
{
    while(true)
    {

    }
}

The increase in current consumption and seemingly broken UART can be reproduced as follows:

• Override STDIO_UART_TX to either PB_3 or PA_0

• Override STDIO_UART_RX to either PB_4 or PA_1

  #include "mbed.h"

  Serial pc(PA_2, PA_3, 9600);
  Serial modem(PB_6, PB_7, 9600);

  int main()
  {
  while(true)
  {
  pc.printf("Help!\r\n");
  ThisThread::sleep_for(2000);
  }
  }

[kjbracey]

To be clear, do you actually need 3 UARTs here - PC, modem and console? Or are you happy losing the console?

The console wiring is presumably fixed on the board, so you may have no option to change that and keep it working. But you should be able just disable it by setting the config option target.console-uart to false.

Although checking the STM hal, you'd also need to set STDIO_UART_RX and STDIO_UART_TX to NC or something to avoid that error it's generating.

Does the moving/deactivation of the console alone break your PC port? Or does it only break when you initialise the modem port?

[amitchone]

So I only need PC and modem. I normally just redirect console to my PC UART (using mbed::mbed_override_console to catch any errors.

The custom board is only a 1st prototype at the moment so there is room to re-wire if needs be, but I think this is something that can be solved in software - I can't see any reason why we should be unable to have the PC and modem UARTs and, using mbed::mbed_override_console, redirect the console output to my PC UART.

I've tried setting the STDIO_UART_TX/RX to NC and the issue remains. It seems that the PC port works and the modem port does not. Simply defining the modem port causes the current consumption to jump to ~50mA.

Is there a way to explicitly specify which hardware peripheral each Serial object uses? Could both UARTs be attempting to use the same hardware peripheral?

[kjbracey]

Using mbed_override_console to go to your PC port is fine, as long as you don't double-initialise.

There's no explicit way to choose hardware peripheral - it's determined by looking up the pins you specify in the pinmapping table. In the case where there are two peripherals of the same type on the same pin set, you may not be able to change it, except by changing the table.

Some targets do offer extra virtual pin settings like PB_3_UART4 you can use to disambiguate.

For the Murata ABZ, I see in the table

• PA2,PA3 -> UART_2 (alt func 4)
• PB6,PB7 -> UART_1 (alt func 4)
• PA9,PA10-> UART_1 (alt func 4)
• PA2_ALT0, PA3_ALT0 -> LPUART_1 (alt func 6)

But cross-referencing that against the comment block in stm32l0xx_hal_gpio_ex.h, the PB6,PB7 looks wrong. I think they should be on alt func 0, so the table entries should say GPIO_AF0_USART1

[kjbracey]

Offending lines:

mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L0x2xZ/TARGET_MTB_MURATA_ABZ/PeripheralPins.c

Line 107 in 0d26be4

{PB_6, UART_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_USART1)},

mbed-os/targets/TARGET_STM/TARGET_STM32L0/TARGET_STM32L0x2xZ/TARGET_MTB_MURATA_ABZ/PeripheralPins.c

Line 117 in 0d26be4

{PB_7, UART_1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF4_USART1)},

Table entry suggesting it should be AF0:

mbed-os/targets/TARGET_STM/TARGET_STM32L0/device/stm32l0xx_hal_gpio_ex.h

Lines 406 to 407 in 0d26be4

	* PB6 |USART1 |I2C1 |LPTIM1_T|TSC | | | | |
	* PB7 |USART1 |I2C1 |LPTIM1_I|TSC | | |USART4 | |

[amitchone]

I can confirm that, if I correct the table entry to GPIO_AF0_USART1, the current consumption no longer increases.

I'm still having trouble getting both UARTs to work but we're making progress

[amitchone]

Another addition to this, if I define the STDIO_UART_TX/RX pins as NC, it appears that none of my UARTs work. For example, a simple UART echo sketch on my PC port (PA2/PA3) doesn't work. I can spam data to the device and will occasionally receive spurious/gibberish output

[kjbracey]

Most targets have some weird handling of the stdio UART pins - it's kind of legacy behaviour to let you get away with doing Serial pc(USBTX, USBRX) in the program - effectively double-initialising the port (once in the stdout init, and again in the program).

Once you've overridden mbed_override_console, Mbed OS itself shouldn't care what those pins are defined as, but the legacy behaviour inside the target code can remain, including that error you were getting.

Maybe on this platform you should define them as PA_2_ALT0 and PA_3_ALT0 to make sure they're a totally different peripheral (LPUART_1).

[amitchone]

So, defining the STDIO_UART pins as PA_2_ALT0 and PA_3_ALT0 allows both the PC port and modem port (PA_2/PA_3 and PB_6/PB_7) respectively to work. Unfortunately we don't currently have a console output so will have to bear that in mind for the timebeing.

Overriding mbed_override_console either before or after defining the two Serial objects breaks the PC port.

Alas, for now I can just develop with this limitation in mind. I'm not planning on having leaky memory anytime soon...

Thanks for all of your help - shall I submit a PR with the fixes to PeripheralPins.c or do you plan to do some further investigation?

Thanks for your help again,
Adam

[kjbracey]

Please go ahead make the PR for GPIO_AF0_USART1.

It would be nice to sort out the other issues too. Turning off target.console-uart really should kill anything referencing those pin defines. It should prevent that runtime error, as nothing should be looking at STDIO_UART_TX if it's off - it shouldn't need to be defined.

And I don't know why providing mbed_override_console should break anything, if the target is specifying PA2_ALT0 as its uart console pins. Mbed OS won't get around to opening anything on those pins, because the override steps in, but that shouldn't upset anything.

What exactly does your mbed_override_console look like? Maybe it's an initialisation order thing. If your PC serial port is a global static, maybe it hasn't yet been constructed when mbed_override_console is first called to return a pointer to it.

Wrapping it up in a SingletonPtr<Serial> will ensure construction on first reference, avoiding that issue.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOTRIAGE-2321

[0xc0170]

PR #11850 was integrated.

What else is there that this issue keeps opened ? @amitchone Please review