I'm seeing some odd behavior on a Kinetis (K60) when erasing sector 0 in the program flash. Erasing sector 0 with a debugger, seems to erase (or invalidate) the rest of my flash. I ran the following sequence with a debugger
put content into sector 0, 1, 2, 3
reset
check content - all OK
erase sector 3, reset, check OK
erase sector 1, reset, check OK
So now there is data in sector 0 and 2. I can read it back OK.
Erase sector 0. reset. flash a vectortable etc into sector 0. reset.
Now sector 0 has content and is readable, but sector 2 (and any other sector that had data) now reads as 0xff.
I'm pretty sure I'm not doing anything to request a mass erase.
The debugger reports the same sector erase time for sector zero as for other sectors, and confirms it thinks it only erased sector 0.
There is nothing explicitely programmed into the security bytes, so they are effectively all 0xff.
Is this a side effect of the flash security? Is the flash controller doing a background erase or just invalidating the data?
Is there somewhere that its documented (I can't see anything relevant in AN4507) and is it posible to stop it happening?
Thanks
Solved! Go to Solution.
Ok, I think I now understand whats happening, so I'll put a note here in case its useful to anyone else.
The problem seems to revolve around whether you reset/reboot the CPU after you have erased sector 0.
So if in code you erase sector 0, then reboot and use the debugger to re-write sector 0, the flash will be empty.
But, if in code you erase sector 0, re-write sector 0 and then reset/reboot, everything is still there just fine.
So there is something wierd going on, probably when the CPU re-boots. But in any real application you shouldn't see it. So the answer is "carry on regardless" and it will all be OK....
Ok, I think I now understand whats happening, so I'll put a note here in case its useful to anyone else.
The problem seems to revolve around whether you reset/reboot the CPU after you have erased sector 0.
So if in code you erase sector 0, then reboot and use the debugger to re-write sector 0, the flash will be empty.
But, if in code you erase sector 0, re-write sector 0 and then reset/reboot, everything is still there just fine.
So there is something wierd going on, probably when the CPU re-boots. But in any real application you shouldn't see it. So the answer is "carry on regardless" and it will all be OK....
Hi lineage,
It sounds like the debugger is playing tricks on you. If your security bits are 0xFF, you shouldn't be able to view the memory in the debugger as JTAG and EZPORT access are restricted in this state (as described in AN4507). You say that you erase sector 0, reset, flash a vector table to sector 0, and then reset again? Try flashing the correct value to the SEC bits (0b10) in the FSEC field and see if that helps.
Hope this helps,
Chris
Hi AppsMan
I thought that it was the debugger at the beginning, but I can't find any evidence to support that.
On the FSEC field, I may have been less that 100% accurate. The protection block is 'as erased' but actually FSEC doesn't erase to 0xff - it erases to 0xfe
0x00000400: ff ff ff ff ff ff ff ff ff ff ff ff fe ff ff ff
Update: I just tried erasing the single sector 0 from code. Same behavior, so it is definately not the debugger. The other erased sectors in flash also appear accept a new write without needing me to erase first (need to do more tests of that to be 100% certain since I'm re-flashing what was previously there).
Cheers
Message was edited by: lineage
Hello Lineage,
any breakthroughs so far?
Let us know :smileywink:
best regards,
Monica.
Hi Monica,
No, not really. Since it happens with an external debugger and it happens when I erase the single sector from software, then I'm discounting the debugger erasing things it shouldn't. And since I can erase other single sectors OK its not a single sector limit.
My current assumption is this is an Undocumented behavior/Errata on the K60 that is an indirect result of the unfortunate decision to put the flash/cpu security/protection data in sector 0 of the flash!
Whats odd is no one else is claiming to have seen it, or to see different behavior. So since it doesn't seem to be bothering anyone else, and I can work around it, then its probably not worth spending too much effort on. I've just put it down to thats how the chip behaves, even if its not documented. Nothing unique about that. To be honest it is a bit annoying in development, especially while developing bootloaders, but when this design goes into manufacturing, sector zero will be written once so the problem won't be seen.
Thanks for taking an interest though.