initializing UARTserial leads to error when SLEEPTRACE enabled

[CodingGhost]

Description of defect

when "MBED_SLEEP_TRACING_ENABLED" Macro is defined, initializing UARTserial leads to an MBEDOS "Not allowed in ISR context" fault.
It is enough to just initialize it with a given baudrade (I tested with 9600) to reproduce this issue.

Target(s) affected by this defect ?

NRF5x Cordio
(maybe more?)

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

PlatformIO 4.2.1

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

5.14.1

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

PlatformIO 4.2.1

How is this defect reproduced ?

UARTSerial *ser = NULL; ser = new UARTSerial(P0_6,P0_8,9600);

add "MBED_SLEEP_TRACING_ENABLED" macro.

[ciarmcom]

@CodingGhost thank you for the update.It appears however that there is still some missing information:

Could you add some more detail to the description? A good description should be at least 25 words.

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.

[ciarmcom]

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

[0xc0170]

What is the callstack (code flow in this case) ? Looking at the code flow for UARTSerial ctor, I suspect there is critical section invoked and mutex being accessed when tracing is enabled.

We will have a closer look.

[kbarm]

Looks like a duplicate of #11497, the call stack is a bit different though:

Thread #2 [Handler mode] 2 (SVCall) (Suspended : Breakpoint)	
	error_msg() at mbed_rtx_handlers.c:101 0x80038d8	
	trap_rtx_error() at mbed_rtx_handlers.c:115 0x800391a	
	EvrRtxMutexError() at mbed_rtx_handlers.c:140 0x80039f0	
	osMutexAcquire() at rtx_mutex.c:483 0x8004c34	
	singleton_lock() at SingletonPtr.h:54 0x8002b1c	
	__cxa_guard_acquire() at mbed_retarget.cpp:1 682 0x8002b1c	
	default_console() at mbed_retarget.cpp:353 0x8002bba	
	get_console() at mbed_retarget.cpp:372 0x8002c14	
	mbed::mbed_file_handle() at mbed_retarget.cpp:386 0x8002c38	
	write() at mbed_retarget.cpp:778 0x8002c9a	
	mbed_error_puts() at mbed_board.c:97 0x80020fa	
	mbed_error_vprintf() at mbed_board.c:71 0x8002142	
	mbed_error_printf() at mbed_board.c:55 0x800215e	
	sleep_tracker_lock() at mbed_power_mgmt.c:167 0x8002892	
	lp_ticker_set_interrupt() at lp_ticker.c:462 0x8007d44	
	schedule_interrupt() at mbed_ticker_api.c:294 0x80016b4	
	initialize() at mbed_ticker_api.c:100 0x80017d2	
	ticker_set_handler() at mbed_ticker_api.c:300 0x8001802	
	mbed::TimerEvent::TimerEvent() at TimerEvent.cpp:31 0x80008d0	
	mbed::internal::SysTimer<1000ul, true>::SysTimer() at SysTimer.cpp:78 0x8001a2c	
	mbed::internal::init_os_timer() at mbed_os_timer.cpp:53 0x8002680	
	OS_Tick_Enable() at mbed_rtx_idle.cpp:80 0x8003ae6	
	svcRtxKernelStart() at rtx_kernel.c:247 0x8003e48	
	SVC_Handler() at irq_cm4f.S:63 0x8003b42	

[hugueskamba]

It does not seem to be purely related to UARTSerial.
It crashes with the following:

#include "mbed.h"
#define WAIT_TIME_MS 500 
DigitalOut led1(LED1);
int main()
{
    printf(str);
    while (true)
    {
        led1 = !led1;
        thread_sleep_for(WAIT_TIME_MS);
    }
}

I built and flashed with the following:
mbed compile -t arm -m disco_l475vg_iot01a -f --sterm

My mbed_app.json has:

{
    "target_overrides": {
      "*": {
        "target.c_lib": "small",
        "target.printf_lib": "minimal-printf",
        "platform.minimal-printf-enable-floating-point": false,
        "platform.stdio-minimal-console-only": true,
        "target.macros_add": ["MBED_SLEEP_TRACING_ENABLED"]
      }
    }
}

I am using mbed-os-6.0.0-rc1.

[hugueskamba]

When the kernel is initialised, the millisecond ticker is started and a timing
request is scheduled using the lp_ticker. The lp_ticker for the STM targets calls
the sleep lock functions which cause tracing to try to print and initialises
the console for the first time causing the board to crash because it is
trying to init the console with IRQ disabled or rather because the kernel is not yet initalised.

This issue is not visible with non-STM boards because they do not use sleep
lock functions in their lp_ticker implementation.