Kinetis MicrocontrollersのトピックRe: Initial flash access in KL02Z

Initial flash access in KL02Z

haimf — Mon, 29 Jun 2015 16:02:17 GMT

Hi,

I am trying to implement flash configuration functionality on the FRDM-KL02Z board using SWD interface.

According to the documentation, in order to perform any FTFA flash operation, the CCIF bit in the FTFA_STAT register must be set.

From the bit description:

The CCIF bit is reset to 0 but is set to 1 by the memory controller at the end of the reset initialization

sequence. Depending on how quickly the read occurs after reset release, the user may or may not see the

0 hardware reset value.

When I tried to implement these operations on a board after flash mass erase operation, I saw that the CCIF bit is never being set.

Only after burning a demo firmware using the USB interface, I saw the respond, and the bit was set.

My question is, what is setting this bit? According to the document, the memory controller is supposed to initialize it, so is it firmware related?

I would appreciate if you can provide some explanation about the boot sequence and how it initiates the flash interface.

If I have a new board, how can I access it with no FW uploaded to it?

Re: Initial flash access in KL02Z

mjbcswitzerland — Tue, 30 Jun 2015 10:54:40 GMT

Hello

A mass erase (+ reset) sets the chip's security so no flash operations are possible until the chip is unsecured again.

Loading new code with the debugger will remove the security.

To avoid this, you need to perform a mass erase, followed by writing the Flash configuration to an unsecure state, before resetting and then subsequent Flash operations will not be blocked.

Regards

Mark

Kinetis: µTasker Kinetis support

KL02: µTasker FRDM-KL02Z support

For the complete "out-of-the-box" Kinetis experience and faster time to market

Re: Initial flash access in KL02Z

haimf — Tue, 30 Jun 2015 13:15:58 GMT

Hi Mark,

Thanks a lot for the quick reply.

I have 3 follow-up questions:

1. What is the case of a new (out of the box) uP. Can I assume that it comes unsecured, so I will be able to access the flash?

2. Why writing the Flash configuration to an unsecure state after mass erase removes the security?

3. Can you please explain how the debugger removes the security?

Thanks,

Haim

Re: Initial flash access in KL02Z

mjbcswitzerland — Wed, 01 Jul 2015 10:38:29 GMT

Haim

1. I think that they are unsecured but I wouldn't assume anything.

2. After a mass erase the chip is unsecured but after a reset it becomes secured again when the Flash configuration is all 0xff. Therefore, the Flash configuration has to be written "after" the mass erase "but" before the reset because that is the only time that it is possible.

3. Debuggers do a mass erase and write the Flash configuration to unsecure a device - exactly as the SW needs to do.

Regards

Mark

Kinetis: µTasker Kinetis support

KL02: µTasker FRDM-KL02Z support

For the complete "out-of-the-box" Kinetis experience and faster time to market

Re: Initial flash access in KL02Z

Jorge_Gonzalez — Thu, 02 Jul 2015 02:50:44 GMT

Hello Haim F:

In addition to Mark's comments, I recommend you to give a check to the next application note about flash programming:

http://cache.freescale.com/files/microcontrollers/doc/app_note/AN4835.pdf

It will resolve many of your doubts.

Let us know if you face further questions.

Regards!

Jorge Gonzalez

Re: Initial flash access in KL02Z

haimf — Thu, 02 Jul 2015 18:35:09 GMT

Mark and Jorge,

Thanks a lot for your help, it really helped me a lot and I was able to progress.

I followed the document that Jorge attached and used this sequence for the initialization:

Keep reset low and establish communication with the ARM DAP. The MDM-AP ID register can be read to verify that the connection is working correctly.
Read the MDM-AP status register until the Flash Ready bit sets.
Read the System Security bit to determine if security is enabled. If System Security = 0, then proceed. If System Security = 1, then communication with the internals of the processor, including the flash, will not be possible without issuing a mass erase command or unsecuring the part through other means (backdoor key unlock).
Write the MDM-AP register to set the Core Hold Reset bit. This will prevent the core from attempting to boot when the reset pin is released. NOTE: the Core Hold Reset bit cannot be written if the processor is secured.
Negate the RESET signal or clear the System Reset Request bit in the MDM-AP control register.

After doing so, I get the access to the flash registers but when I am trying to burn the image, I still see 2 issues:

When I do sector erase, after I erase sector 2 (starting at address 0x400) that contains the flash configuration, the next SWD operation that I do will return with fault ACK (0x4), and I am not able to recover from it.
When I try to program the flash using multiple Program Long Word commands, after several of these commands I see the Access Error Flag bit in the FSTAT register is set, so that indicated the operation failed. I suspect it is because of some security mode issue, but I am not sure.

Is there anything else in the initialization sequence that I am missing?

BR,

Haim