HardFault on return from main() since mbed-os-5.8.0

[bmcdonnell-ionx]

Description

• Type: Bug
• Priority: Major | Minor

In previous versions through mbed-os-5.7.7, the OS would handle a return from main() gracefully. As of mbed-os-5.8.0, doing so produces a Hard Fault.

I know it is typical in embedded systems not to return from main(), as there is (at least conceptually) nothing to return to. Please EITHER

• patch mbed-os-5.8 to produce the previous behavior, OR
• update the documentation and all examples to reflect the current behavior.

---

Bug

Target
LPC4088
EDIT: Embedded Artists' LPC4088 QuickStart Board

Toolchain:
GCC_ARM

Toolchain version:
Whatever comes with MCUXpresso IDE v10.1.1 [Build 606] [2018-01-02].

mbed-cli version:
1.5.0
with ARMmbed/mbed-cli#642

mbed-os sha:
addec7ba1 (HEAD -> mbed-os-5.8, tag: mbed-os-5.8.1, tag: latest, origin/mbed-os-5.8) Merge pull request #6461 from ARMmbed/release-candidate

DAPLink version:

Expected behavior

Either:

• Mbed OS handles return from main() gracefully as before, OR
• all examples do not return from main(), and documentation explains why.

Actual behavior

For example, using the latest mbed-os-example-filesystem (with mbed-os-5.8.1), I get this console output at the end.

[snip]
Unmounting... OK
Mbed OS filesystem example done!
++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 100020D0
R1   : 00000000
R2   : 10000E2C
R3   : 10000110
R4   : 00000000
R5   : 00000000
R6   : 00000000
R7   : 00000000
R8   : 00000000
R9   : 00000000
R10  : 00000000
R11  : 00000000
R12  : 10003090
SP   : 1000FFB0
LR   : FFFFFFED
PC   : 00003450
xPSR : 410F000B
PSP  : 100030B0
MSP  : 1000FF90
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000000
BFSR : 00000004
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
SHCSR: 00000080
Mode : Handler
Priv : Privileged
Stack: MSP

Thread Info:
Current:
State: 00000000 EntryFn: 0000349B Stack Size: 00000000 Mem: 00001B39 SP: 0000348B
Next:
State: 00000002 EntryFn: 00007E5D Stack Size: 00000200 Mem: 10000EC0 SP: 10001080
Wait Threads:
State: 00000083 EntryFn: 000076ED Stack Size: 00000300 Mem: 100010C0 SP: 10001328
Delay Threads:
Idle Thread:
State: 00000002 EntryFn: 00007E5D Stack Size: 00000200 Mem: 10000EC0 SP: 10001080

-- MbedOS Fault Handler --

Parsing that with crash_log_parser, I get this.

$ ./crash_log_parser.py crash-log--mbed-os-example-filesystem.txt mbed-os-example-filesystem.axf mbed-os-example-filesystem.map

Crash Info:
        Crash location = SVC_ContextSwitch [0x00003450] (based on PC value)
        Caller location = __exidx_start [0xFFFFFFED] (based on LR value)
        Stack Pointer at the time of crash = [1000FFB0]
        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
                Imprecise data access error has occurred

Steps to reproduce

[0xc0170]

@bmcdonnell-ionx Are you able to reproduce with any other target?

@geky (as filesystem is used in the example above) - are you able to reproduce this?

I can't think of what has changed between 5.7.7 and 5.8 that would cause this. I checked mbed boot, has not changed for 5.8. So this might be target specific?

[bmcdonnell-ionx]

@0xc0170 I don't have other targets.

(as filesystem is used in the example above) - are you able to reproduce this?

@0xc0170, @geky This doesn't appear to have anything to do with the file system. (That was just the first example I came across that returns from main().) I still get the HardFault with only the following in main.cpp.

#include "mbed.h"

#define SERIAL_BAUD_RATE  (115200)

static Serial SerialPort(USBTX, USBRX, SERIAL_BAUD_RATE);

int main()
{
   printf("\r\ntest\r\n");
}

[bmcdonnell-ionx]

I edited the OP to add my target board (Embedded Artists' LPC4088 QuickStart Board).

[bmcdonnell-ionx]

To be clear, I should probably say the Hard Fault occurs "following return from main()", not "on return from main()".

[bmcdonnell-ionx]

@0xc0170, this issue does not occur when I use mbed compile -t GCC_ARM, nor if I just turn an LED on instead of doing printf(). I think the root cause here is the MCUXpresso exporter, likely the same as #6661 (comment).

[deepikabhavnani]

@bmcdonnell-ionx - Dont want to divert the existing analysis here, but would like to know with which version of GCC_ARM toolchain you see this issue? With toolchain version "6-2017-q2-update" and above I have seen crashes in standard library calls (printf / scanf).

[bmcdonnell-ionx]

@deepikabhavnani, as discussed in the other issue I linked, this appears to be an issue with the flags passed to the assembler, not the compiler/toolchain itself.

So I don't know that it's relevant, but yes, I'm also using GCC_ARM toolchain "6 2017-q2-update".

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-96

[SenRamakri]

As seen in the comment from @bmcdonnell-ionx this was due to exporter issue which is already tracked in #6661. So closing this.