Hard faults running a ram application on FRDM-K66F

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Hard faults running a ram application on FRDM-K66F

跳至解决方案
1,436 次查看
andrewparlane2
Contributor III

I have a couple of FRDM-K66F eval boards, and a K66 on one of our own custom boards.

I'm trying to write a small RAM application that can program it's flash. The idea is we mass erase the chip using the MDM-AP over SWD. Then we load a RAM application, and the new flash FW into internal SRAM. This runs programming internal flash and reports back it's state.

I created a new K66 project using the MK66FX1M0xxx18_ram.ld linker script provided in the KSDK (SDK_2.1_MK66FN2M0xxx18).

I am programming it using the K20 on the FRDM-K66F using KDS v3.2. I created a new GDB Segger J-Link debugging launch config using the default (auto created settings) except I set the "RAM application" checkbox in the startup tab.

It programs and verifies into RAM OK. However it never hits the auto created breakpoint on main(). Stepping through from Reset_Handler in startup_MK66F18.s we branch into SystemInit() and hard faults on:

SCB->CPACR |= ((3UL << 10*2) | (3UL << 11*2));    /* set CP10, CP11 Full Access */

excerts from objdump:

1fff04c8 <Reset_Handler>:
1fff04c8: b672 cpsid i
1fff04ca: 4809 ldr r0, [pc, #36] ; (1fff04f0 <Reset_Handler+0x28>)
1fff04cc: 4909 ldr r1, [pc, #36] ; (1fff04f4 <Reset_Handler+0x2c>)
1fff04ce: 6001 str r1, [r0, #0]
1fff04d0: 4809 ldr r0, [pc, #36] ; (1fff04f8 <Reset_Handler+0x30>)
1fff04d2: 4780 blx r0

......

1fff04f0: e000ed08 .word 0xe000ed08
1fff04f4: 1fff0000 .word 0x1fff0000
1fff04f8: 1fff23bd .word 0x1fff23bd

......

1fff23bc <SystemInit>:
1fff23bc: b480 push {r7}
1fff23be: af00 add r7, sp, #0
1fff23c0: 4b0b ldr r3, [pc, #44] ; (1fff23f0 <SystemInit+0x34>)
1fff23c2: 4a0b ldr r2, [pc, #44] ; (1fff23f0 <SystemInit+0x34>)
1fff23c4: f8d2 2088 ldr.w r2, [r2, #136] ; 0x88

......

1fff23f0: e000ed00 .word 0xe000ed00
1fff23f4: 40052000 .word 0x40052000

It crashes on instruction at address 1fff23c4.

register r2 contains 0xe000ed00.

I then tried disabling that line (by turning off hard floating point) in the toolchain options. Which caused a very similar failure in the watchdog disable code. When it tries to write to memory address: 0x4005200E (wdog unlock register).

I can't find any examples of ram apps for the kinetis chips, so not sure if I'm missing something obvious or not.

Thanks,

Andrew

标签 (1)
0 项奖励
回复
1 解答
987 次查看
andrewparlane2
Contributor III

I managed to solve this myself.

For anyone else looking, the problem was that the SP register wasn't being set up. This normally happens on system startup using the default vector table at address 0x0000_0000 (in flash). However that was 0xFFFF_FFFF since my flash was erased.

Not entirely sure why it crashed on the store instruction rather than the push instruction.

There are two ways to solve this. One set up the debug config / launch config to set the SP correctly.

Or you can modify startup_MK66F18.s adding:

ldr     sp, =__StackTop /* Set sp. Only needed in ram apps */

I added that just after setting up the vtor table.

Reset_Handler:
    cpsid i /* Mask interrupts */
    .equ VTOR, 0xE000ED08
    ldr r0, =VTOR
    ldr r1, =__isr_vector
    str r1, [r0]
    ldr sp, =__StackTop /* Set sp. Only needed in ram apps */

#ifndef __NO_SYSTEM_INIT
    ldr r0,=SystemInit
    blx r0
#endif

I've also tested the above change with a flash app and although SP was already set correctly before the ldr sp instruction, the instruction just reloads it to the same value. So the only downside is one extra instruction during boot.

在原帖中查看解决方案

1 回复
988 次查看
andrewparlane2
Contributor III

I managed to solve this myself.

For anyone else looking, the problem was that the SP register wasn't being set up. This normally happens on system startup using the default vector table at address 0x0000_0000 (in flash). However that was 0xFFFF_FFFF since my flash was erased.

Not entirely sure why it crashed on the store instruction rather than the push instruction.

There are two ways to solve this. One set up the debug config / launch config to set the SP correctly.

Or you can modify startup_MK66F18.s adding:

ldr     sp, =__StackTop /* Set sp. Only needed in ram apps */

I added that just after setting up the vtor table.

Reset_Handler:
    cpsid i /* Mask interrupts */
    .equ VTOR, 0xE000ED08
    ldr r0, =VTOR
    ldr r1, =__isr_vector
    str r1, [r0]
    ldr sp, =__StackTop /* Set sp. Only needed in ram apps */

#ifndef __NO_SYSTEM_INIT
    ldr r0,=SystemInit
    blx r0
#endif

I've also tested the above change with a flash app and although SP was already set correctly before the ldr sp instruction, the instruction just reloads it to the same value. So the only downside is one extra instruction during boot.