To get the combined benefits of the FRDM-64F platform, the mbed libraries, and the KDS IDE, I created the following KDS project that compiles, and allows for step-by-step debugging of mbed applications, including step through of mbed source code.

https://github.com/bundgus/K64F-mbed-KDS-Template

Thanks to everyone in the mbed community for your contributions, hopefully this will be useful to you. I'm sure there are many improvements to be made. Feel free to fork this configuration, and let me know if you have any suggestions.

The sample application in this template project is the K64F Disco Blinky application.

-Mark

Hello Mark,

thanks for sharing ! KDS exporters are enabled in beta mode, you should be able to export any program to KDS and run it.

By the way, I am working in my free time on project generator. I does not support KDS at the moment, but will do one day :-) Which means that you wouldn't need to check in KDS project files, just create records and easily port your application to various toolchains/IDEs.

Regards, 0xc0170

Nice effort guys, thanks for sharing.

I will be testing it soon, and post here the results :)

I gave the beta KDS exporter a try, but no luck.

I noticed that the HAL_CM4.s and SVC_Table.s files were not recognized until I converted their suffix to a capital S - HAL_CM4.S and SVC_Tables.S.

And, I did get a hard fault at rtos::Thread::Thread() at Thread.cpp:44 0x1a86.

Is this possibly an issue with the default stack and heap size, when using the RTOS?

In my working project I had to set the following symbols in the assembly preprocessor:

"STACK_SIZE=0x8000" "HEAP_SIZE=0x8000" NO_INIT_DATA_BSS

Hi Mark, are you on github? you can create an issue. I recall .S problem in KDS, will need to be fixed.

Regarding stack and heap size, GCC startup file for K64F defines them as follows:

#ifdef __STACK_SIZE
    .equ    Stack_Size, __STACK_SIZE
#else
    .equ    Stack_Size, 0xC00
#endif
    .globl    __StackTop
    .globl    __StackLimit
__StackLimit:
    .space    Stack_Size
    .size __StackLimit, . - __StackLimit
__StackTop:
    .size __StackTop, . - __StackTop

    .section .heap
    .align 3
#ifdef __HEAP_SIZE
    .equ    Heap_Size, __HEAP_SIZE
#else
    .equ    Heap_Size, 0x400
#endif

Share once you find out why it goes to Hard fault.

Regards,
0xc0170

I did some additional experimentation both with the Freescale KDS toolchain, and the GNU Tools for ARM Embedded Processors (https://launchpad.net/gcc-arm-embedded). I changed the stack and heap settings, and I think I've ruled that out.

It looks like the hard fault when running the KDS toolchain occurs in:

rt_List.c void rt_put_rdy_first (P_TCB p_task)

While looking at the disassembly view, it looked like one of the registers (R3) was populated with a real value (0x1fff04b0) when running the GNU Arm toolchain, but it was zero (showed 0x0) when using the KDS toolchain.

If R3 is 0x0, it looks like this assembly command may be trying to load a value into address 0x4, which is a read-only memory location?

str r2, [r3, #4]

See attached debugger screen shots for more detail.

One other thing I checked was the value in the Configurable Fault Status Register (0xE000ED29). Prior to the hardfault, it looks like this register is set to 0b010, indicating IMPRECISERR - Imprecise data bus error:

1 = a data bus error has occurred, but the return address in the stack frame is not related to the instruction that caused the error. When the processor sets this bit to 1, it does not write a fault address to the BFAR. This is an asynchronous fault. Therefore, if it is detected when the priority of the current process is higher than the BusFault priority, the BusFault becomes pending and becomes active only when the processor returns from all higher priority processes. If a precise fault occurs before the processor enters the handler for the imprecise BusFault, the handler detects both IMPRECISERR set to 1 and one of the precise fault status bits set to 1.

I noticed that I got a significantly different .map file from each linker and have attached those as well.

The only difference between the working and non-working configurations in KDS, was the toolchain, and the linker flags that had to be different between the two tool chains: -specs=nano.specs -specs=nosys.specs for the GCC Arm toolchain and -nanolibc for the KDS toolchain.

Any ideas? Linker configuration error, or linker bug, perhaps?

KDS toolchain just before hard fault:

GCC Arm toolchain at the same location, no fault:

@Mark Bundgus, can you explaing how you did that? I would like to do the same thing but for FRDM-25KL board.