STM32: #8286 Causes Tickless RTC Mode App to Hang

[mattbrown015]

Description

cc @jeromecoutant

#8286 causes our app to hang and behave badly in ways that I find difficult to describe.

I've been using the previous PR, #8323, for several days without any problems. As soon as I apply the change from #8262 the app starts hanging.

From mbed_app.json:

{
...
"macros": [
...
,"MBED_TICKLESS"
...
],
"target_overrides": {
"*": {
...
,"target.lpticker_lptim": 0
,"target.lpticker_delay_ticks": 0
...
}

If I start the app from cold, i.e. RTC == 0, not very much happens. I don't see any of our debug trace from main but I can tell from the current consumption the STM is running.

If I attach a debugger I can see the following:

update_present_time (ticker=ticker@entry=0x803193c <lp_data>) at .\mbed-os\hal\mbed_ticker_api.c:127
127 ticker_event_queue_t *queue = ticker->queue;
(gdb) bt
#0 update_present_time (ticker=ticker@entry=0x803193c <lp_data>) at .\mbed-os\hal\mbed_ticker_api.c:127
#1 0x0800f96a in ticker_insert_event_us (ticker=0x803193c <lp_data>, obj=obj@entry=0x200045d0 <os_timer_data+8>, timestamp=, id=id@entry=536888776) at .\mbed-os\hal\mbed_ticker_api.c:353
#2 0x0800808e in mbed::TimerEvent::insert_absolute (this=this@entry=0x200045c8 <os_timer_data>, timestamp=) at .\mbed-os\drivers\TimerEvent.cpp:53
#3 0x080109ae in rtos::internal::SysTimer::schedule_tick (this=0x200045c8 <os_timer_data>, delta=delta@entry=1) at .\mbed-os\rtos\TARGET_CORTEX\SysTimer.cpp:128
#4 0x08010a48 in rtos::internal::SysTimer::handler (this=0x200045c8 <os_timer_data>) at .\mbed-os\rtos\TARGET_CORTEX\SysTimer.cpp:185
#5 0x0800f940 in ticker_irq_handler (ticker=0x803193c <lp_data>) at .\mbed-os\hal\mbed_ticker_api.c:313
#6 0x080188f2 in RTC_IRQHandler () at .\mbed-os\targets\TARGET_STM\rtc_api.c:331
#7
#8 hal_critical_section_exit () at .\mbed-os\hal\mbed_critical_section_api.c:60
#9 0x0800fc70 in core_util_critical_section_exit () at .\mbed-os\platform\mbed_critical.c:99
#10 0x080109b6 in rtos::internal::SysTimer::schedule_tick (this=, delta=delta@entry=1) at .\mbed-os\rtos\TARGET_CORTEX\SysTimer.cpp:130
#11 0x08010f96 in OS_Tick_Enable () at .\mbed-os\rtos\TARGET_CORTEX\mbed_rtx_idle.cpp:54
#12 0x080115b0 in svcRtxKernelStart () at .\mbed-os\rtos\TARGET_CORTEX\rtx5\RTX\Source\rtx_kernel.c:267
#13 0x08010fe2 in SVC_Handler () at irq_cm4f.S:63
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)

Or something very similar.

If I use the debugger to reset the STM, I guess this doesn't reset the RTC, our app will start but then it gets stuck around the time it is likely to decided to sleep. If I fiddle around, resetting etc., it might start running normally. In other words, if I can get it running it then starts behaving itself.

I've tried applying #8013.

I've also tried adding more critical sections and/or making them larger in rtc_api.c.

I'm just going to try build with ARM GCC V6, instead of V7, but after that I haven't got any more ideas.

Can anyone suggest anything else to try?

Slightly related but not the cause of my problems...

It looks to me like rtc_write is missing a called to core_util_critical_section_exit if _rtc_localtime fails. Although in practice, I don't think _rtc_localtime will fail.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug

[mattbrown015]

I tried ARM GCC V6 and V7, the behaviour is the same.

Forgot to mention that this an STM32L442KC although regulars readers might know that! :-)

[jeromecoutant]

Hi

I've also tried adding more critical sections and/or making them larger in rtc_api.c

Try to remove them.. supposing that critical sections are managed at mbed hal level...

[jeromecoutant]

Maybe you can try to increase lpticker_delay_ticks value to check ?

Also during my TICKLESS tests, I was using #8223 fix with a latency of 5 for ex

[mattbrown015]

Unfortunately those ideas haven't worked. :-(

I've tried #8223 with 0, 5, 10 and 100 and it didn't make any difference. That doesn't surprise me because it would be strange if deepsleep was being entered early in the startup sequence.

I removed all the critical sections from rtc_api.c with no apparent change in behaviour. I haven't looked in detail but it could be changing the problem.

My feeling is that it has got something to do with the RTC time being zero and/or the RTC not enabled.

I wondered if there was anything in the options bytes related to the RTC? I looked in the RM and didn't see anything that seemed relevant.

I should also point out that I'm applying #8427.

[mattbrown015]

I've given up with our app for now and created a test app which, on the face of it, works.

Our real app includes multiple threads and multiple event queues.

Interestingly one of the threads is started in the constructor of a global object. If that caused a problem we wouldn't make it to main.

I shall start adding some threads and events queues to see if I can cause a problem.

Here's what I've done that works:

#include <mbed.h>

int main() {
    puts("tickless-8286 #18d6131 " __TIME__ );

    while (1) {
        putchar('.');
        fflush(stdout);

        ThisThread::sleep_for(60 * 1000);
    }
}

mbed-os.lib:

https://github.com/ARMmbed/mbed-os/#18d613111f278d5b5991bb830f064eb797cbce84

mbed_app.json:

{
    "artifact_name": "tickless-8286",
    "macros": [
       "MBED_TICKLESS"
    ],
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": "115200"
            ,"target.lpticker_lptim": 0
            ,"target.lpticker_delay_ticks": 0
        }
    }
}

[mattbrown015]

Well, adding a Thread object is enough to break it.

This code never makes it to main after a power-on reset.

#include <mbed.h>

Thread thread;

int main() {
    puts("tickless-8286 #18d6131 " __TIME__ );

    while (1) {
        putchar('.');
        fflush(stdout);

        ThisThread::sleep_for(60 * 1000);
    }
}

[jeromecoutant]

@c1728p9 @LMESTM

[jeromecoutant]

I don't know. Here is some thinking:

• tickless feature should start with lp_ticker_init function which calls rtc_init ?
• TIME calls time mbed api, which calls rtc_isenabled
  • from cold start, rtc_isenabled should answer 0, then set_time(0) is called ?

[jeromecoutant]

I think I got the issue!

mbed-os/targets/TARGET_STM/rtc_api_hal.h

Line 84 in c40d860

#define PREDIV_S_VALUE RTC_CLOCK / (PREDIV_A_VALUE + 1) - 1

I forgot parenthesis :
#define PREDIV_S_VALUE (RTC_CLOCK / (PREDIV_A_VALUE + 1) - 1)

[mattbrown015]

Extra parentheses work for me! :-)