K60 - ARM runtime standard library crashing on branch to __main

[erickcastillo]

Hello,

I'm currently working on a bare metal bootloader using AN2295 as our launch pad. We have found the need for using the runtime library (malloc & scatterloading) but discovered that using the standardlib causes a crash the instant we branch to __main. Here's what I've done to assess the problem.

1. --thumb & --library_type=standardlib are both explicitly specified (confirmed with --info=libraries to the linker).

2. Created a startup.S file with low level initialization that disables the watchdog before jumping into the standardlib __main function.

3. Main function in bootloader.c uses the following signature: int main(void);

4. The 16 entries of the vector table all point to a reset handler with the exception of index 0 which is the stack pointer location and index 1 which is a pointer to the startup assembly.

During execution, I can see that my low level initialization of the watchdog and peripheral clocks is happening correctly. Watchdog is disabled and all peripherals are on. However, as soon as we try the branch to __main, I fault into one of my reset vectors!

My current workaround is to use the microlib, which appears to be working with the exact same codebase and set up described above. My suspicion is that maybe I'm missing a compiler/linker flag that is causing the wrong stuff to get linked in? Or is it simply that the standardlib is not available for the K60?

While the workaround is getting me past the initial hurdle, I'd like to know if anyone has had any luck linking the standardlib so that I'm able to do it just in case.

More Info:

Platform: K60 (MK60FN1M0)

IDE: Eclipse Indigo /w Keil uVision 5 plugin

Board: TWRK60

Debug: P&E Micro debug driver

Thanks in advance,

--Erick

[Kan_Li]

Hi Erick,

did you add the compiling options as below?

Actually I did the same to the Blinky project in the folder of "C:\Keil_v5\ARM\Boards\Freescale\TWR-K60N512\Blinky", and tested it with TWR-K60N512, but seems it works well as expected.

Would you please help to confirm if I missed something else?

Thanks for your patience!

Have a great day,
Kan

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

[erickcastillo · Accepted solution]

Hi Kan,

After a month of avoiding this problem, I actually had to come back to it since malloc/calloc were returning NULL with microlib and I needed to try standardlib again. My discovery on crashing standard library: the system was self-resetting in the clib because "_fp_init" within clib was trying to configure the FPU when privileges for the coprocessors had not been enabled! Once I enabled the coprocessors (via SCB->CPACR register), I managed to get through clib init and into my app.

Regards,

--Erick

[erickcastillo]

Hi Kan,

Thanks for checking this out.

I took your lead and decided to try out my methods with the blinky project. I even made the linker do what I do on my Eclipse build (adding ARM_LIB_HEAP and ARM_LIB_STACK in the scatter file) and everything appears to work fine. I could step through the library scatter loading disassembly and Blinky runs fine in uVision. I will look more closely at my Eclipse build options and compare them to blinky and see what I find. It may even be related to the IDE; who knows? I'll post an update once I have one.

Thanks,

--Erick