K60 Bootload via AN4367... Stupid Question

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

K60 Bootload via AN4367... Stupid Question

Jump to solution
1,179 Views
snowkid
Contributor I

Great Ap Note... Coded into two designs... works like a champ!

So here's my stupid question:  How come this works????

This approach to bootload involves executing and programing Flash memory in the K60 all confined to Block 0. How is it that I am not seeing read while write issues??? 

See this from AN4367 (note, the application itself is loaded into 0x0000_C0000):

The bootloader is placed into the first 48 KB of the on-chip flash memory, but the actual size of the bootloader can be smaller. The user application can be placed into the flash area above the bootloader flash area. The last 4 KB of the flash memory must be reserved for the bootloader's parameters storage, which is defined by the size of the erase-page of the on- chip flash memory.

The following figure shows the memory map and the bootloader memory footprint. The bootloader code is located in the first address of the flash memory, 0x0000_0000 to 0x0000_BFFF. The bootloader parameters are located in the first address of the last logical-block of the flash memory, 0x0007_F000 to 0x0008_0000 (in Kinetis MK60n512).

bootmap.jpg

 
Tags (3)
0 Kudos
Reply
1 Solution
726 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

This is possible because there is a small piece of code executed out of RAM.

/* == Should be in the RAM ==*/

#if FNET_CFG_COMP_CW

    #pragma define_section FNET_RAM ".FNET_RAM" ".FNET_RAM" ".FNET_RAM" far_abs RX

  __declspec(FNET_RAM)

#endif

#if FNET_CFG_COMP_IAR

    __ramfunc

#endif

 

static 

#if FNET_CFG_COMP_UV

    __attribute__((section("FNET_RAM"))) __attribute__((used))

#endif

void fnet_ftfl_command_lunch_inram(void)

{

    FNET_MK_FTFL_FSTAT = FNET_MK_FTFL_FSTAT_CCIF_MASK;

    while (!(FNET_MK_FTFL_FSTAT & FNET_MK_FTFL_FSTAT_CCIF_MASK))

    {};

}

It is not executing from block 0 while flashing the block.

I hope this helps,

Alejandro

View solution in original post

0 Kudos
Reply
2 Replies
727 Views
alejandrolozan1
NXP Employee
NXP Employee

Hi,

This is possible because there is a small piece of code executed out of RAM.

/* == Should be in the RAM ==*/

#if FNET_CFG_COMP_CW

    #pragma define_section FNET_RAM ".FNET_RAM" ".FNET_RAM" ".FNET_RAM" far_abs RX

  __declspec(FNET_RAM)

#endif

#if FNET_CFG_COMP_IAR

    __ramfunc

#endif

 

static 

#if FNET_CFG_COMP_UV

    __attribute__((section("FNET_RAM"))) __attribute__((used))

#endif

void fnet_ftfl_command_lunch_inram(void)

{

    FNET_MK_FTFL_FSTAT = FNET_MK_FTFL_FSTAT_CCIF_MASK;

    while (!(FNET_MK_FTFL_FSTAT & FNET_MK_FTFL_FSTAT_CCIF_MASK))

    {};

}

It is not executing from block 0 while flashing the block.

I hope this helps,

Alejandro

0 Kudos
Reply
726 Views
snowkid
Contributor I

Thank you Alejandro -

The odd thing is: one of my designs I definitely do not jump to RAM (FNET was doing this for me on the other as you pointed out).  The only guess I have is that maybe the instruction cache prevented the error?  At any rate it has been redesigned to use page 1.  Thank you for your reply.

0 Kudos
Reply