Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
geobruce opened this issue Dec 14, 2018 · 23 comments

Comments

Projects
None yet
9 participants
@geobruce
Copy link

commented Dec 14, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

Hi

quick question:

when using latest mbed-os-5.10.4

Does it mean it was working with 5.10.3 ?

@geobruce

This comment has been minimized.

Copy link
Author

commented Dec 14, 2018

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

This comment has been minimized.

Copy link
Author

commented Dec 14, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 14, 2018

@geobruce

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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-arm

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2018

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:

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

@jeromecoutant

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2018

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

@geobruce

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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-arm

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2018

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

This comment has been minimized.

Copy link
Author

commented Dec 17, 2018

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

@geobruce

This comment has been minimized.

Copy link
Author

commented Dec 21, 2018

I tested version 5.11.0 but no succes yet.

@screamerbg

This comment has been minimized.

Copy link
Contributor

commented Jan 25, 2019

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

@LMESTM

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jan 28, 2019

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

@deepikabhavnani

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2019

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

@geobruce

This comment has been minimized.

Copy link
Author

commented Jan 30, 2019

@deepikabhavnani

This comment has been minimized.

Copy link
Contributor

commented Jan 30, 2019

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

@jeromecoutant

This comment has been minimized.

Copy link
Contributor

commented Feb 1, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 9, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Apr 11, 2019

@geobruce - Please verify #10367

@0xc0170

This comment has been minimized.

Copy link
Member

commented Apr 17, 2019

@geobruce - Please verify #10367

Any update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.