Wait() function causes system to hang on STM32F0(91RC)

[geobruce]

Description

The “simple mbed blinky program” does not work on the NUCLEO-F091RC when using latest mbed-os-5.10.4 .
The problem occurs when using the wait function. The program compiles but when flashed the delay is not working and halts the microcontroller. This problem occurs with all possible mbed wait functions.
The problem seems similar to an earlier “bug” #1494 for and older version of mbed, maybe it is the same problem again.

/* mbed Microcontroller Library
 * Copyright (c) 2018 ARM Limited
 * SPDX-License-Identifier: Apache-2.0
 */
#include "mbed.h"
#include "stats_report.h"
DigitalOut led1(LED1);
int main()
{
   // SystemReport sys_state(500 /* Loop delay time in ms */);
    while (true) {
        led1 = !led1;
        wait(0.5f); // osDelay(500);     
        //sys_state.report_state();
    }
}

When I leave the wait function commented, the program runs and I can slow the program down with:

       for(int i = 0 ; i<10000;i++){
           printf("%i\r\n",i);
       }

So I’m pretty sure my toolchain is configured correctly and there might be something wrong with the libraries.

I was able to get this "error report" from the "serial monitor (putty)" when I discovered the problem with the wait function when I was using a different program. But the problem is already visible by running the blinky program.

-- MbedOS Error Info --

++ MbedOS Error Info ++Error Status: 0x80020125 Code: 293 Module: 2
Error Message: CMSIS-RTOS error: Stack overflow
Location: 0x8003DFF
Error Value: 0x1
Current Thread: Id: 0x20001010 Entry: 0x8003DC9 StackSize: 0x200 StackMem: 0x20001098 SP: 0x20007EB0
For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80020125
-- MbedOS Error Info --

Issue request type

[ ] Question
[ ] Enhancement
[x ] Bug

[jeromecoutant]

Hi

quick question:

when using latest mbed-os-5.10.4

Does it mean it was working with 5.10.3 ?

[geobruce]

I don't know about that, but I know the online compiler behaves differently because it seems to use mbed2.
I noticed:
In the online compiler: the wait function works, but printf does not.
In the offline compiler mbed-cli+visual studio code: the wait function does not work, but the printf works.

[geobruce]

Hi

quick question:

when using latest mbed-os-5.10.4

Does it mean it was working with 5.10.3 ?
I tested it in platformio they use version 5.10.1 and there it still works.

[ciarmcom]

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-321

[geobruce]

I located the error to be in the debug profile. When I build the project with the develop profile it is working. But not when flashing with the debug profile.

[kjbracey]

The thing that immediately sprints to mind is that deep sleep is disabled by the debug, profile, because mbed_sleep_manager.c responds to MBED_DEBUG. Can you try just manually editing the condition here:

mbed-os/hal/mbed_sleep_manager.c

Line 211 in b9927e5

#ifdef MBED_DEBUG

for both develop and debug builds (so try stopping develop deep sleeping, and letting debug deep sleep).

[jeromecoutant]

But I don't think deep sleep is used as TICKLESS has not been enabled.

[geobruce]

The thing that immediately sprints to mind is that deep sleep is disabled by the debug, profile, because mbed_sleep_manager.c responds to MBED_DEBUG. Can you try just manually editing the condition here:

mbed-os/hal/mbed_sleep_manager.c

Line 211 in b9927e5

#ifdef MBED_DEBUG
for both develop and debug builds (so try stopping develop deep sleeping, and letting debug deep sleep).

I'm not totally sure what you would like me to try. But I changed
#ifdef MBED_DEBUG hal_sleep(); #else if (sleep_manager_can_deep_sleep()) { deep = true; hal_deepsleep(); } else { hal_sleep(); } #endif
to
#ifdef MBED_DEBUG //hal_sleep(); if (sleep_manager_can_deep_sleep()) { deep = true; hal_deepsleep(); } else { hal_sleep(); } #else if (sleep_manager_can_deep_sleep()) { deep = true; hal_deepsleep(); } else { hal_sleep(); } #endif

But I don't think that's what you meant, and it didn't help.

[kjbracey]

Ah, as Jerome said, if MBED_TICKLESS isn't on, then that code isn't invoked anyway, and we're always shallow sleeping.

If the error is solid, and you have an version that it worked on, maybe go back to git bisect to find the mbed OS commit that broke it?

[geobruce]

At the moment I build using the develop profile, that way I can't debug, but the mbed functions do work.

[geobruce]

I tested version 5.11.0 but no succes yet.

[screamerbg]

@jeromecoutant This is one of the Mbed Enabled boards? Could you please look at the issue?

[LMESTM]

The mbed-os error explicitly reports a "Stack overflow" and the stack size seems to be 0x200 (while main default stack size is often 0x4000). Has the default stack size been strongly reduced / optimized in recent releases ? Or the interrupt stack size ?
Maybe the changes in timer drivers to support tickless and other advanced operation require a slight increase of the stack size ...

[jeromecoutant]

#8956 was not part of 5.11.0
Could you also check latest release ?
Thx

[deepikabhavnani]

@geobruce - Debug profile has MBED_TRAP_ERRORS_ENABLED flag enabled, can you disable that and see if wait works in debug profile?
https://github.com/ARMmbed/mbed-os/blob/master/tools/profiles/debug.json#L33

Other error reported is stack overflow, and stack size is 0x200 which is for Idle thread.
In case of wait() call, if no other thread is ready, idle thread will be executed which is the case with blinky application.
Please try increasing the stack size of idle thread to 0x400, and note if blinky works in debug profile without any changes in profile.
https://github.com/ARMmbed/mbed-os/blob/master/rtos/mbed_lib.json#L15

[deepikabhavnani]

Is this related to #7235 ? Fix to this was added #7241 in 5.9.2 release.

[geobruce]

With "-DMBED_TRAP_ERRORS_ENABLED=1"], set to "-DMBED_TRAP_ERRORS_ENABLED=0"], no success, It doesn’t work still same serial output “test0” and nothing more. When I change the stack size from 512 of the idle thread to 1024 it does work and I’m able to execute the code step by step. Van: Deepika Bhavnani <[email protected]> Verzonden: woensdag 30 januari 2019 6:44 Aan: ARMmbed/mbed-os <[email protected]> CC: geobruce <[email protected]>; Mention <[email protected]> Onderwerp: Re: [ARMmbed/mbed-os] Wait() function causes system to hang on STM32F0(91RC) (#9106) @geobruce<https://github.com/geobruce> - Debug profile has MBED_TRAP_ERRORS_ENABLED flag enabled, can you disable that and see if wait works in debug profile? https://github.com/ARMmbed/mbed-os/blob/master/tools/profiles/debug.json#L33 Other error reported is stack overflow, and stack size is 0x200 which is for Idle thread. In case of wait() call, if no other thread is ready, idle thread will be executed which is the case with blinky application. Please try increasing the stack size of idle thread to 0x400, and note if blinky works in debug profile without any changes in profile. https://github.com/ARMmbed/mbed-os/blob/master/rtos/mbed_lib.json#L15 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#9106 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AErciFj36gAr2v_XSws39wRfEQmgZf0cks5vITEEgaJpZM4ZTcse>.

[deepikabhavnani]

@geobruce - Please verify if #9559 fixes the issue, else we can increase the stack size to 1024.

[jeromecoutant]

For me, #9559 is not correct. I can't see any argument to increase idle stack only for this F091 without any condition...

Solution would be more something like #8551,
i.e. depending on some configuration (was TICKLESS in #8551, it is some DEBUG macro for this one), idle stack is increased.

[deepikabhavnani]

@jeromecoutant - The fix was requested from ST team to reduce the stack usage for deep sleep, will like to know if any updates on that?

[jeromecoutant]

Hi
Test done with mbed-os-example-blinky and GCC tool chain:

• NUCLEO_L152RE: idle stack size = 336
• NUCLEO_L152RE changing compilation option from Os to O0: idle stack size = 828
• NUCLEO_F091RC: idle stack size = 360
• NUCLEO_F091RC changing compilation option from Os to O0: idle stack size = 548

[jeromecoutant]

@geobruce - Please verify #10367

[0xc0170]

@geobruce - Please verify #10367

Any update?