Unprotecting Flash in KL26 (???)

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

Unprotecting Flash in KL26 (???)

Jump to solution
2,119 Views
mjbcswitzerland
Specialist V

Hi All

I just had a mishap. Using the Flash programming utility of Codewarrior I loaded a hex file thinking that it was an srec hex file (whereby it was Intel hex).

The result was that it was handled as a binary file and loaded its ASCII content to flash.

The FTFA_PROT values were set with "0B38" - or 0x30, 0x42, 0x36, 0x38 which has protected a number of flash sectors from being erased/programmed, including sector 0.

This device doesn't have an NVM special mode and it is not possible to modify the PROT values using a debugger so that sector 0 can be erased.

Codewarrior can't do an erase of the protected sectors and nor can any other tools that I have - also a mass erase is blocked when any sector is protected.

FSEC is at 0x32 (mass storage enabled and not secured) and FOPT 0x39 (fast init and reset pin dedicated, NMI enabled and OUTDIV1 is 0x01) but these seem to be harmless.

Trying to load a small program to SRAM to unlock and erase sector 0 hasn't been successful since the code exceptions on every instruction (can't execute a single line), NMI is '1' so I don't see what is stopping it...

Is there a standard way out? Would EZPORT allow unprotecting?

Regards

Mark

- being curious I couldn't resist looking into this some more and am getting the feeling that whatever I loaded to the board has really made the device unusable.
- If I load code to the SRAM I can read back the code normally. It is however impossible to run the code. Below I have copied a clip from the debugger screen showing that the disassemble window shows all good (code in SRAM from the address) - I also moved the PC to an instruction that doesn't use memory to ensure that it is purely internal. WHen executing a single step the hard fault exception is called (I think - since it jumps to an address that happens to be programmed at the Flash address 0x0000000c).
- When I load the same code to a KL25 board with no weird Flash configuration it has no problems and can step the code.

Is it possible that some configuration is not allowing instruction execution in SRAM? I didn't find any setting that would block core instruction accesses.

SRAM_debug.PNG.png

Labels (1)
Tags (1)
1 Solution
933 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hi Mark:

I'm afraid there is no EZPORT in Kinetis L devices, so you need to stick to the SWD mass erase.

SWD certainly supports mass erase command, but you are correct, I am not so sure about OpenSDA bridge, this would be a question for P&E.

About CodeWarrior, the Flash Programmer tool should send a mass erase command, or even the debug configurations with P&E connections have an option to mass erase before programming. You may try to program a new empty application and select that option. Check this:

Mass_erase.png

Also, I found the appnote at the next link suggesting to hold the reset line while mass erasing via SWD. I recommend you to read chapter 4 (especially 4.1.1, 4.2, 4.2.1 and 4.2.1.1):

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

Hope this helps

Regards!

Jorge Gonzalez

View solution in original post

0 Kudos
6 Replies
933 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hello Mark:

The problem with not running in RAM is indeed strange, right now I cannot think of an explanation. But even if you achieved to run from RAM, that would not help, since you cannot "unprotect" sectors, just increase protection.

However, I think you should still be able to mass erase the device with a SWD tool. AFAIK the mass erase restriction is just for the "Erase All Blocks" Flash command, which is implemented by code. Did you tried a mass-erase and it did not work?. In case you did, I guess the only option is a J-link with "Unlock Kinetis" command or a mass-erase script.

Regards!

Jorge Gonzalez

933 Views
mjbcswitzerland
Specialist V

Hi Jorge

I could increase protection but not remove it using the debugger and saw that Erase All Blocks was failing. I was hoping that maybe the CPU running code would have rights to unprotect (I have used the protection on Coldfires where it was possible to temporarily remove it if not fully locked out), which the debugger doesn't have but you are correct that this is not the case. I looked at AN4507 and there it states that it is only possible to unprotect using a mass erase command via EZPORT or JTAG (since the flash protection settings are not valid for it).

CW flash utility was deleting flash but then failing the blank check since the deletes were not responding. As far as I know CW doesn't support a mass erase command (would that not be practical if it could?).

The K26 FRDM board uses an OpenSDA via SWD and I don't know at the moment whether that interface supports the mass erase command (?).

Connecting JTAG or EZPORT may be a bit messy since the board has its on.board debugger connected but I may go for EZPORT when I have some time to connect it up.

The SRAM instruction behaviour is certainly puzzling and that is why I thought that there was maybe an undocumented bit in the Flash config area somewhere.

Another weird thing is that the iHEX file that I mistakenly loaded was about 60k in size and so I expected to find the upper 64k of Flash blank. Also, since not all areas are protected I also expected to find some of them deleted after the chip erase with CW. But, if I look through the 128k addres space I find the typical iHEX pattern (all BCD) there in every single sector - from 0...128k with no gaps; as if the Flash size has been reduced and the content is wrapping around...

For the moment it is not possible to do any sensible with the board so hopefully the EZPORT mass erase will prove to solve it once I get around to building a connector or some sort.

Thanks.

Regards

Mark

0 Kudos
934 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

Hi Mark:

I'm afraid there is no EZPORT in Kinetis L devices, so you need to stick to the SWD mass erase.

SWD certainly supports mass erase command, but you are correct, I am not so sure about OpenSDA bridge, this would be a question for P&E.

About CodeWarrior, the Flash Programmer tool should send a mass erase command, or even the debug configurations with P&E connections have an option to mass erase before programming. You may try to program a new empty application and select that option. Check this:

Mass_erase.png

Also, I found the appnote at the next link suggesting to hold the reset line while mass erasing via SWD. I recommend you to read chapter 4 (especially 4.1.1, 4.2, 4.2.1 and 4.2.1.1):

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

Hope this helps

Regards!

Jorge Gonzalez

0 Kudos
933 Views
mjbcswitzerland
Specialist V

Hey Jorge !!

Simply selecting "Always mass erase on contact" and loading some code did the trick.


When I load a project to SRAM it also runs again too!!!

Thanks a million - I didn't even need to do anything with the reset line.

Regards

Mark

933 Views
Jorge_Gonzalez
NXP Employee
NXP Employee

That's good to know Mark!!

This actually helps understanding that OpenSDA supports mass erase command. And also, I will try later, but seems that the Flash Programming Utility does not serve to mass-erase as I stated.

Regards!

Jorge Gonzalez

0 Kudos
933 Views
mjbcswitzerland
Specialist V

Hi Jorge

In fact I have seen that the "Connection" selected when using the "Flash File To target" in the Flash Utility is the same one as used to download project code and thus has the option "Always mass erase on connect". This means that it would supposedly be possible to do the same using this and commanding "Erase Whole Device".

However it may make things simpler if there were a new button added. There is already the command "Erase Whole Device" and a new one called something like "Mass Erase Device (unlocking protection)" would be perfect since it would mean that people without detailed knowledge of the settings could simply work out what to do and the setting could be used for a "single-shot" rather than them having to be set back again afterward. This would probably avoid having to support such problems in the future since most people will find the solution themselves with little effort.

Regards

Mark