Skip to content

Hard fault when printing sleep info on NUCLEO-F446RE #10079

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

Closed
janjongboom opened this issue Mar 13, 2019 · 10 comments
Closed

Hard fault when printing sleep info on NUCLEO-F446RE #10079

janjongboom opened this issue Mar 13, 2019 · 10 comments

Comments

@janjongboom
Copy link
Contributor

janjongboom commented Mar 13, 2019

Description

My board immediately hard faults after starting up when printing sleep info. Running in tickless mode, with sleep stats enabled on Mbed OS 5.11.5 (51d5550).

Application:

#include "mbed.h"
#include "mbed_stats.h"

static DigitalOut led(LED1);
static LowPowerTicker t;

void blink() {
    led = !led;
}

int main() {
    printf("Hello from C++\n");

    t.attach(&blink, 2.0f);

    while (1) {
        mbed_stats_cpu_t stats;
        mbed_stats_cpu_get(&stats);
        // printf("Uptime: %llu ", stats.uptime / 1000);
        // printf("Sleep time: %llu ", stats.sleep_time / 1000);
        printf("Deep Sleep: %llu\n", stats.deep_sleep_time / 1000);

	    // printf("LED is %d\n", led.read());

        wait_ms(5000);
    }
}

mbed_app:

{
    "target_overrides": {
        "*": {
            "platform.stdio-baud-rate": 115200,
            "platform.stdio-convert-newlines": true
        },
        "NUCLEO_F446RE": {
            "target.macros_add": [
                "MBED_CONF_TARGET_STDIO_UART_TX=D8",
                "MBED_CONF_TARGET_STDIO_UART_RX=D2"
            ]
        }
    },
    "macros": [
        "MBED_TICKLESS=1",
        "MBED_CPU_STATS_ENABLED=1",
        "MBED_CONF_TARGET_TICKLESS_FROM_US_TICKER=0"
    ]
}

Error message:

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 2000106C
R1   : 00000000
R2   : 20001058
R3   : FFFFFFFF
R4   : 00000001
R5   : 20000D34
R6   : 00000003
R7   : 00000000
R8   : 00000000
R9   : 00000000
R10  : 00000000
R11  : 00000000
R12  : 08003095
SP   : 200029A8
LR   : 080069A3
PC   : FFFFFFFE
xPSR : 01000000
PSP  : 20002988
MSP  : 2001FFC0
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000001
BFSR : 00000000
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x800062F
Error Value: 0xFFFFFFFE
Current Thread: main  Id: 0x2000197C Entry: 0x800227B StackSize: 0x1000 StackMem: 0x200019C0 SP: 0x2001FF5C 
For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80FF013D
-- MbedOS Error Info --

Which means:

Crash Info:
	Crash location = __exidx_start [0xFFFFFFFE] (based on PC value)
	Caller location = __libc_init_array [0x080069A3] (based on LR value)
	Stack Pointer at the time of crash = [200029A8]
	Target and Fault Info:
		Processor Arch: ARM-V7M or above
		Processor Variant: C24
		Forced exception, a fault with configurable priority has been escalated to HardFault
		MPU or Execute Never (XN) default memory map access violation on an instruction fetch has occurred

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug
@janjongboom
Copy link
Contributor Author

Setting MBED_CONF_APP_IDLE_THREAD_STACK_SIZE=2048 solves this issue. So similar to #7235. Can we add some tests around idle thread sizes when logging is enabled? This has broken before in the 5.9 release.

@jeromecoutant
Copy link
Collaborator

Fix as #8551 ?
@c1728p9 @LMESTM

@janjongboom
Copy link
Contributor Author

@jeromecoutant That was released in 5.10.4, this current issue is verified against 5.11.5.

@jeromecoutant
Copy link
Collaborator

Yes, patch was something like:

#if MBED_TICKLESS
#define EXTRA_IDLE_STACK xxx

New patch would be

#if STATS
#define EXTRA_IDLE_STACK xxx

@ciarmcom
Copy link
Member

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

@0xc0170
Copy link
Contributor

0xc0170 commented Mar 20, 2019

Yes, patch was something like:

Does it fix it?

@janjongboom
Copy link
Contributor Author

Well upping idle thread stack size should help indeed, but given that we run into the same issue again we should be more careful about sizes of these stacks when enabling traces, and we should also have tests around this.

@cmonr
Copy link
Contributor

cmonr commented Mar 25, 2019

@SenRamakri ^^^

@jeromecoutant
Copy link
Collaborator

@janjongboom Could you verify #10702 impact, and/or close the issue ?
Thx

@janjongboom
Copy link
Contributor Author

@jeromecoutant I'm no longer with Arm, so if someone from core team could validate this, that'd be great.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants