STM32L486RG/MTB_ADV_WISE_1570 losing data when mbed tickless is enabled

[soleilplanet]

Description of defect

When MBED_TICKLESS is set to 1, there are data losses observed on multiple peripherals.
For example, cellular stack using ATHandler. The UART is receiving corrupted data when tickless and enabled. An example case is when the modem repots SIM Ready, it sends back a string of 'READY', but the cellular stack sometimes receives 'RDY', sometimes, receives 'ADY', sometimes receives
the full 'READY'.
Same situation observed with SPI Block Device. when tickless is enabled, the file system read sometimes reads back corrupted data.
Issue will not be observed when tickless is disabled with the same code.
We've observed similar issue on F4 series and it was a timing issue of deep sleep, so tried to test a few combinations of configurations. So far the following configuration works on my board for your reference:
"lpticker_delay_ticks": 4
"deep-sleep-latency": 3

Target(s) affected by this defect ?

STM32L486RG
MTB_ADV_WISE_1570

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

GCC
ARMC6
(IAR was not tested)

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

mbed-os-5.14.1

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

mbed-cli 1.10.0

How is this defect reproduced ?

For WISE-1570, it has a NB-IoT on it, so just run cellular example on it and you can observe it. It is much easier to reproduce with modem interface baudrate 115200 and with mbed-trace enabled in debug level; the cellular stack just cannot ramp up to the network because it cannot get through the SIM check due to the missing bytes in AT commands.

[0xc0170]

cc @ARMmbed/team-st-mcd

[MarceloSalazar]

@soleilplanet would you be able to share a simple connectivity application with the configuration that could let us reproduce this issue?

[LMESTM]

One input: "lpticker_delay_ticks" should better be set to 0 than any other value when TICKLESS is enabled. Having "lpticker_delay_ticks" > 0 means that the LP ticker C++ wrapper will be used and it was proved to induce high latencies.

"deep-sleep-latency": 3
Recent measurments have shown that deep sleep latencie can be more than 3ms and we've moved it to 5 by default on STM32 targets. The actual value actually depends on the HW and the clock configuration, but I guess you can increase it to more 5 or more (10?) to verify if it has any impacts. This will lower the chances that deep-sleep is entered for very shot period of time.

One more note :
I don't know MTB_ADV_WISE_1570 and this would need support from another team than ST.
do you have HW flow control enabled on the serial link and has the modem driver implemented a protocol for low power mode entry and exit ?

[soleilplanet]

@MarceloSalazar here it is:
mbed-cloud-client-example-sleepy-test.zip
targets.json need to be modified to enable tickless; code is based on PDMC4.0.0
@LMESTM for lpticker_delay_ticks, when it's 0, there is stack overflow error right after boot. WISE-1570 does not have HW flow control for LPUART if I'm not mistaken; only UART 3 has CTS/RTS pins. This issue not only happens with cellular stack. I can sometimes see FCC reading corrupted credentials from KCM and thus KCM (stored on SPI flash) is being reset, and in that case cellular stack has not initialized yet.

[LMESTM]

@LMESTM for lpticker_delay_ticks, when it's 0, there is stack overflow error right after boot.

Then let's fix the stack overflow. I confirm you'd better set lpticker_delay_ticks to 0.
This is being detailed here: #10701.
Low level ticker wrapper require Extra Idle stack - so you'd also need to add "EXTRA_IDLE_STACK_REQUIRED", to your target.

See 6331034

Once you've done that let's see if you're still hitting SPI issues. Also SPI frequency might need to be lowered for increased stability and relax the latency constraint on SPI driver.

About not using HW Flow control for the connection to the modem, I feel like it may be a design limitation. Are you able to ensure ensure that your system will always allow UART RX registers to be read in less than 100µs or so ?

[jeromecoutant]

Hi
Any update?
Please align first configuration for MTB_ADV_WISE_1570 with default configuration of NUCLEO_L486RG
Thx

[soleilplanet]

Hi @jeromecoutant
Sorry for the late update. I just applied all defaults from L486RG and it is still the same (stack overflow).
I've tried PDMC and the blinky example and both are the same.

[jeromecoutant]

Maybe you could share a git branch with your changes?

[soleilplanet]

@jeromecoutant https://github.com/soleilplanet/mbed-cloud-client-example/tree/ADV_WISE_1570
This is the config which would work; when lpticker delay is set back to 0, I see the stackoverflow.

[jeromecoutant]

Hi
Please use jeromecoutant@83576eb
And remove from your local mbed_app to remove default configuration overrides.