Swappin Mechanism on K60

[Rodion]

Hi,

I am trying to implement a boot loader, that will located on Flash Block 0 and it will receive a SREC file via UART, erase Block 1 and program it with 0x00040000 offset. At the end of these operations, the Boot should to swap between Flash Blocks.

At this stage I am able to erase and program the flash Block 1 with SREC that belong to a simple GPIO example from Kinetis_Eval projects.

In my boot loader code, after the erase/program section I put these commands:

/* enable the clock to SRTC module register space*/

SIM_SCGC6 |= SIM_SCGC6_RTC_MASK;

/* activate swap */

RTC_CCR = 0x1;

When I made a hw reset or wdog reset, MCU jumps to Block 0, and not to Block1.

I use IAR Kickstart 6.2 workbench and MK60N512VLL100 MCU.

Any suggestion on how should I activate the swapping mechanism?

Regards,

Rodion.

[mjbcswitzerland]

Rodion

Setting RTC_CR to 0x1 resets the real time clock so I don't see a relation to the FLASH swap. To do the FLASH swap the swap command needs to be executed in the Flash memory module (details in section 28 of the user's manual).

Note that the present state of the "swap" is indicated in the registers SIM_FCFG2 and FTFL_FCNFG.

Also I wonder why you want to swap the blocks as a part of the boot loader since this seems an extra complication and will also make for incompatiility with X parts which don't have this capability. It also limits the code size to half of the available space.

SREC serial, Ethernet and USB loaders are included in the uTasker project for IAR, CW, GCC, Keil and Rowley Crossworks in case you prefer to use an 'off-the-shelf' one (with optional encryption for code protection and power-cycle resistent remote loading using intermediate internal or external storage):

The UART loader is documented here: http://www.utasker.com/docs/uTasker/uTaskerSerialLoader.PDF

Regards

Mark

[Rodion]

Hi Mark,

Thank you for your response.

The RTC_CR register, that you mentioned here is located on 0x4003_D010 address, and it is RTC control register, The register that I mentioned called RTC_CCR and it’s located on 0x4003_D01C address.

As you can see on K60 Sub-Family Reference Manual, Rev. 4, 1 Mar 2011 datasheet, on page 105,

section 3.5.1.9 Program Flash Swap,

RTC_CCR activates a swapping mechanism.

“On devices that contain program flash only, the two program flash banks may swap their base addresses. This is controlled by the RTC's chip configuration register (RTC_CCR). See CCR register for more details. The status of the swap feature is reflected in the FTFL's FCNFG[SWAP] bit”.

3.8.6.2 CCR register, page 144

“For devices with only program flash: The RTC's chip configuration register (RTC_CCR) is defined as follows:”

Field Description Bit 0 PFLASHSWAP

Program flash swap.

0 Program flash bank 0 is at address 0x0000_0000

1 Program flash bank 1 is at address 0x0000_0000

Two other registers that you mentioned (SIM_FCFG2, FTFL_FCNFG) only indicates if the swap activated or not.

Regards,

Rodion

[mjbcswitzerland]

Hi Rodion

I would upgrade to the release version of the manual Rev. 5 from 8.5.2011.

This register no longer appears in it (therefore I assumed that the CCR was a typo).

This implies that the register never actually existed in this chip (the description was possibly taken from a different but similar device that did have it).

It would at least explain why you don't get any reaction from it.....;-)

Regards

Mark

[egoodii]

We find that Rev 1.0 silicon had the CCR register and SWAP bit function, but new Rev 1.2 Silicon has an RTC interrupt Enable Register at that same address, and we assume 1.2 silicon implements the 'new'(?)' complicated swapping mechanism I am just now wading thru.

As an aside, for our purposes this 'swap' function is critical to reliable 'bootloader' update.  We dedicate the first 16K (FPROT protection section size) to the bootloader, but when IT needs to be updated we copy (and verify!) this current code out to the first 16K of the second flash block, and enable the 'swap' function so that if any Reset occurs during/after the new bootloader is flashed, the original bootloader will execute from address 0, recognize this condition and restore itself to block 0 section 0 and remove the swap, aborting the bootloader update.  Of course after this process the 496K application space needs to be (re)programmed.