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

Non Rtos build fails for ARM compiler #9523

Closed
deepikabhavnani opened this Issue Jan 28, 2019 · 10 comments

Comments

Projects
None yet
6 participants
@deepikabhavnani
Copy link
Contributor

deepikabhavnani commented Jan 28, 2019

Description

Mbed OS example when built without rtos, fails in init for ARM compiler.
++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x51DB
Error Value: 0x12E6
For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80FF013D
-- MbedOS Error Info -
++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0 : 000073EC
R1 : 00000000
R2 : 000083EC
R3 : 20000104
R4 : 000083EC
R5 : 000073EC
R6 : 000073FC
R7 : 200005DC
R8 : 00000000
R9 : 00000000
R10 : 000071AC
R11 : 000071AC
R12 : 00000000
SP : 2002FFD0
LR : 000012CF
PC : 000012E6
xPSR : 41000000
PSP : 00000000
MSP : 2002FF68
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000000
BFSR : 00000086
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
BFAR : 000073EC
Mode : Thread
Priv : Privileged
Stack: MSP

Crash location = __Heap_Initialize
Caller location = _init_alloc

Steps to compile non-rtos version for blinky:

  1. mbed import mbed-os-example-blinky
  2. Add .mbedignore with following data
    /test/
    mbed-os/rtos/*
    mbed-os/events/*
    mbed-os/features/*
    mbed-os/components/*
  3. Remove mbed_app.json - or set all configs as false.

Issue gets fixed with below change in linker file:

diff --git a/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_ARM_STD/MK64FN1M0xxx12.sct b/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_ARM_STD/MK64FN1M0xxx12.sct
index 72a6efafe2..3a92ddf5b1 100644
--- a/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_ARM_STD/MK64FN1M0xxx12.sct
+++ b/targets/TARGET_Freescale/TARGET_MCUXpresso_MCUS/TARGET_MCU_K64F/device/TOOLCHAIN_ARM_STD/MK64FN1M0xxx12.sct
@@ -131,6 +131,4 @@ LR_IROM1 m_interrupts_start m_text_start+m_text_size-m_interrupts_start {   ; lo
   }
   RW_IRAM1 ImageLimit(RW_m_data_2) { ; Heap region growing up
   }
-  ARM_LIB_STACK m_data_2_start+m_data_2_size EMPTY -Stack_Size { ; Stack region growing down
-  }
 }

Linker file was updated to have stack config option and later use it to have unified stack size across all targets.

Solution:

Correct the implementation of _mbed_user_setup_stackheap which assumes single stack and heap region of IARM1 is present in linker file.

extern "C" MBED_WEAK __value_in_regs struct __initial_stackheap _mbed_user_setup_stackheap(uint32_t R0, uint32_t R1, uint32_t R2, uint32_t R3)

We have alternate implementations for few targets, considering stack and heap as separate regions for Mbed 2 as well.

extern __value_in_regs struct __initial_stackheap _mbed_user_setup_stackheap(uint32_t R0, uint32_t R1, uint32_t R2, uint32_t R3) {

Impact:
#8039 - Affects K64F only and is part of 5.11 release
#9092 - All targets and is for 5,12

Issue request type

[ ] Question
[ ] Enhancement
[X] Bug
@deepikabhavnani

This comment has been minimized.

Copy link
Contributor Author

deepikabhavnani commented Jan 28, 2019

@ciarmcom

This comment has been minimized.

Copy link
Member

ciarmcom commented Jan 28, 2019

@ciarmcom ciarmcom added the mirrored label Jan 28, 2019

@JanneKiiskila

This comment has been minimized.

Copy link
Contributor

JanneKiiskila commented Jan 29, 2019

@adbridge we need this to next patch release, please.

@0xc0170

This comment has been minimized.

Copy link
Member

0xc0170 commented Jan 29, 2019

@mprse Can you please review?

@mprse

This comment has been minimized.

Copy link
Member

mprse commented Jan 29, 2019

I'll try to investigate this one and provide the fix.

@mprse

This comment has been minimized.

Copy link
Member

mprse commented Jan 29, 2019

I was able to reproduce the failure and tried to adapt heap parameters to be consistent with rtos builds:

#if !defined(ISR_STACK_SIZE)
extern uint32_t Image$$ARM_LIB_STACK$$ZI$$Base[];
extern uint32_t Image$$ARM_LIB_STACK$$ZI$$Length[];
#define ISR_STACK_START ((unsigned char*)Image$$ARM_LIB_STACK$$ZI$$Base)
#define ISR_STACK_SIZE ((uint32_t)Image$$ARM_LIB_STACK$$ZI$$Length)
#endif
#if !defined(HEAP_START)
/* Defined by linker script */
extern uint32_t Image$$RW_IRAM1$$ZI$$Limit[];
#define HEAP_START ((unsigned char*)Image$$RW_IRAM1$$ZI$$Limit)
#define HEAP_SIZE ((uint32_t)((uint32_t)ISR_STACK_START - (uint32_t)HEAP_START))
#endif

Current version:

extern "C" char Image$$RW_IRAM1$$ZI$$Limit[];
extern "C" char Image$$ARM_LIB_STACK$$ZI$$Base[];
extern "C" char Image$$ARM_LIB_STACK$$ZI$$Length[];

extern "C" MBED_WEAK __value_in_regs struct __initial_stackheap _mbed_user_setup_stackheap(uint32_t R0, uint32_t R1, uint32_t R2, uint32_t R3)
{
    uint32_t zi_limit = (uint32_t)Image$$RW_IRAM1$$ZI$$Limit;
    uint32_t sp_limit = (uint32_t)Image$$ARM_LIB_STACK$$ZI$$Base;

    zi_limit = (zi_limit + 7) & ~0x7;    // ensure zi_limit is 8-byte aligned

    struct __initial_stackheap r;
    r.heap_base = zi_limit;
    r.heap_limit = sp_limit;
	
    return r;
}

It looks like heap parameters should be valid, but I'm still getting hard fault:

-- MbedOS Fault Handler --



++ MbedOS Error Info ++
Error Status: 0x80FF013D Code: 317 Module: 255
Error Message: Fault exception
Location: 0x51CB
Error Value: 0x12E6
For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80FF013D
-- MbedOS Error Info -▒
++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 000073DC
R1   : 00000000
R2   : 000083DC
R3   : 20000104
R4   : 000083DC
R5   : 000073DC
R6   : 000073EC
R7   : 200005DC
R8   : 00000000
R9   : 00000000
R10  : 0000719C
R11  : 0000719C
R12  : 00000000
SP   : 2002FFD0
LR   : 000012CF
PC   : 000012E6
xPSR : 41000000
PSP  : 00000000
MSP  : 2002FF68
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000000
BFSR : 00000086
UFSR : 00000000
DFSR : 00000008
AFSR : 00000000
BFAR : 000073DC
Mode : Thread
Priv : Privileged
Stack: MSP

@deepikabhavnani Do you maybe have some idea?

@deepikabhavnani

This comment has been minimized.

Copy link
Contributor Author

deepikabhavnani commented Jan 30, 2019

@mprse - Implementation of __rt_lib_init might be needed as well.

* The overriding __rt_lib_init is needed only for rtos-less code. For rtos code, __rt_entry is

More Info:
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/CHDEGGBA.html

With addition of ARM_LIB_STACK in linker file we are changing the memory model for RTOS-less builds to 2-region memory model. This needs approval from @sg-

@deepikabhavnani

This comment has been minimized.

Copy link
Contributor Author

deepikabhavnani commented Jan 30, 2019

@adbridge we need this to next patch release, please.

@ARMmbed/mbed-os-maintainers - Please note the versions when adding the fix. Currently it will fail for all targets on master, since 8039 and 9092 are merged on master.

#8039 affects K64F and was part of 5.11 release, so local fix for K64F can be part of next patch release.
#9092 affects rest of the targets and is for 5.12, so fix for this should be part of 5.12 and not patch release.

@cmonr

This comment has been minimized.

Copy link
Contributor

cmonr commented Jan 30, 2019

@bulislaw ^^^

@mprse

This comment has been minimized.

Copy link
Member

mprse commented Jan 31, 2019

@deepikabhavnani Thanks for link and experimentation of the problem.

Fix can be found here: #9571

I checked that blinky example(rtos-less build) works with this patch. I also removed redundant files for targets which have already used 2-region memory model (as it is now common). The only difference is that these targets defines also ARM_LIB_HEAP region. I added exception for these targets. Please review if such solution is acceptable.

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.