K64 Bootloader Pre-jump Checklist

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

K64 Bootloader Pre-jump Checklist

1,176 Views
kyati
Contributor II

Hi All,

 

I have been continuing a bootloader project, which i had described in K64 FTFE Operations Across PFlash Blocks , by adding some different decision making on when to update the application. The example I based the project off, SD Card Bootloader :how to using SD card to update existing firmware on CodeWarriror or KDS , uses a gpio to determine when to update the program, whereas I want to update if the specific file is detected on the SD card and then delete the file when completed.

 

The code which used a gpio to trigger the update and jump had no issues. The new update which calls f_stat() from FATFS to check if the file exists or not does not always jump to the program. If I continually restart the code after the file is erased and the app is written, (solely checking that the file is not there, turning off peripherals and interrupts, and jumping to app) the app will only run some of the time. When failing, the application code ends up in the application's default ISR after the jump. I feel that this is due to an interrupt being left on, but I globally disabled them and any active peripherals before the jump.

 

One method that causes the code to work properly 100% of the time is setting the first part of the SRAM, including the RAM vector copy, to 0 (0x1FFF0000 to 0x1FFFFFFF).

 

The linker file for my bootloader looks as such:

  m_interrupts          (RX)  : ORIGIN = 0x00000000, LENGTH = 0x00000400   m_flash_config        (RX)  : ORIGIN = 0x00000400, LENGTH = 0x00000010   m_interrupts_ram      (RW)  : ORIGIN = 0x1FFF0000, LENGTH = 0x00000400   m_text                (RX)  : ORIGIN = 0x00000410, LENGTH = 0x000FFBF0   m_data                (RW)  : ORIGIN = 0x1FFF0400, LENGTH = 0x0000FC00   m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00030000

 

The application code is then offset by 0x10000:

  m_interrupts          (RX)  : ORIGIN = 0x00010000, LENGTH = 0x00000400   m_flash_config        (RX)  : ORIGIN = 0x00010400, LENGTH = 0x00000010   m_interrupts_ram      (RW)  : ORIGIN = 0x1FFF0000, LENGTH = 0x00000400   m_text                (RX)  : ORIGIN = 0x00010410, LENGTH = 0x000EFBF0   m_data                (RW)  : ORIGIN = 0x1FFF0400, LENGTH = 0x0000FC00   m_data_2              (RW)  : ORIGIN = 0x20000000, LENGTH = 0x00030000

 

I use the following assembly to jump to the application by passing 0x10000 and 0x10004 as arguments, respectively:

static void JumpToUserApplication(uint32_t userSP, uint32_t userStartup) {   __asm("msr msp, r0");   __asm("msr psp, r0");  __asm("mov pc,  r1"); }

 

I am using KDS 3.1 with baremetal KSDK 1.3 and FATFS on a custom K64 board. I used processor expert to set up the SDHC and sd card peripherals as well as some gpios for status LEDS. I have received some useful information from Bootloader for Kinetis K64 (Cortex M4) on what to do before jumping to the application, but still feel I am missing something. What exactly does clearing the SRAM do that makes the code work? Is there any checklist of tasks I should perform with the KSDK functions before the jump that I may be missing based on my setup?

 

Thanks,

 

Jared

Labels (1)
Tags (3)
0 Kudos
2 Replies

598 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Jared Evans:

In regards to your issue:

- Exactly at what point do you clear the SRAM?

I do not see how this resolves the issue, unless the application uses the same vectors than the bootloader, which are not valid for the application.

- If the application ends up in an unhandled interrupt, you should be able to inspect the ICSR register at address 0xE000ED04 to see which interrupt vector is active:

pastedImage_0.png

- In your call to the jump function the arguments 0x10000 and 0x10004 are only correct if you use them as pointer to 32-bit int and pass the value received from dereferencing them. Otherwise these parameters are wrong.

Let us know if you find any more symptoms that help tracking the issue.

Regards!

Jorge Gonzalez

0 Kudos

598 Views
kyati
Contributor II

Hi Jorge,

Sorry for my late reply. I have been off of this section of the project for a while, but have now had a chance to look into the issue further.

When I initially looked into this problem, I had noticed that if I jumped to the program immediately (not called many other functions in main) it worked correctly. It was only when I, for example, would check if files existed on the SD card that the jump would not correctly work. I figured that the difference was SRAM usage, and tried using memset on m_data, which was successful.

I perform this memset on m_data right before calling the jump instructions.

I looked into the register at 0xE000ED04, which read 0x03F04004, indicating a MemManage exception. The MemManage fault status register is 0x00, and the MemManage fault address register is 0xF8ED00E0. This only occurs when I do not set the SRAM.

If you have any other suggestions for what I can look into, please let me know.

Thanks,

Jared

0 Kudos