"Device is secure. Erase to unsecure?", fails

[mikekaelin]

I have a production design (that I inherited from another company) with a MKL15Z128 processor. During production programming (with a PE Micro Cyclone), we had a bunch of them fail. There was no serial comm with the chip, and Production was unable to reprogram the parts.  I looked at them with a PE Micro Multilink Universal using the KDS software. When I try to program them, I get the message "Device is secure. Erase to unsecure?", and after a couple of attempts the programming fails. Looking at the Reset line on the interface, I see it toggling at about 8-15uS, although it holds low when the interface is trying to do something. There is activity on the other two programming lines.

I'm guessing here - if I assume that the programmer had a bad cable and/or the download got corrupted, is this maybe a watchdog toggling the Reset line? Is it possible that a corrupted download could also lock out device erase? Is this a common occurrence? Is there any way to revive the parts, or do I have to just change them out? The design currently has direct connections to the SWD pins. Is there a requirement (or recommendation) for protection components? Or is the hardware connection to the Multilink generally pretty robust?

I've also seen KDS lose communications with the Multilink, even though Windows could see it in the Device Manager. After rebooting my PC, it worked again. Is this a known problem?

thanks,

Mike.

[joeseymour]

> I'm guessing here - if I assume that the programmer had a bad cable and/or the download got corrupted, is this maybe a watchdog toggling the Reset line?

Yes, having a bad/corrupted application on the device can result in the the device constantly resetting as you describe. If you can get a GDB connection to the target, which might be helped by turning off the "continue" checkbox, and similar options in the debug configuration, then you could try using GDB's compare-sections command to see if your application made it onto the device cleanly. PEMicro may also offer a verification mechanism that doesn't require a GDB connection.

> Is it possible that a corrupted download could also lock out device erase?

> Is there any way to revive the parts, or do I have to just change them out?

If garbage has been written to the FCF register then flash security could have been enabled, and if you were particularly unlucky then mass erase could have been disabled. In that particularly unlucky state I think you'll struggle to get the board back. Search for FSEC in the sub-family reference manual for your part for details.

Assuming mass erase hasn't been disabled than it should unlock the device, however because a mass-erased device doesn't contain a valid program when the device resets you could end up in another reset loop, with security enabled (again). Therefore, its a good idea to get a known-good program onto the device as soon as possible, e.g. use the new project wizard to create an application, check the mass erase on connect button in its debug configuration, then try and debug the application. Hopefully, this will first erase the device, followed by immediately putting a safe application onto it.

Hope that helps,

Joe

[mikekaelin]

Thanks, Joe. That's great help. Just one more quick question - Are you saying in your last paragraph that I might be able to recover the download capability with, say, a really short program that can be downloaded "in between" the resets issuing from processor? Just a throw-away program that sets up the watchdog and registers correctly, then sits in a loop? I have worked with other processors that, during the download, would pulse the reset line a couple of times, and a short program that accidentally generates its own watchdog reset would screw up the download. But usually, it was able to recover.

I already went ahead and changed out the processors in the 6-7 units that failed this way (cheaper than spending a lot of time trying to debug!), but also instituted a cable inspection and replacement schedule. I'll  also include some Production training so they don't try to "thumb" the cable into working.

Again, thanks for your help!

Mike.

[joeseymour]

Glad I could be of some help.

> Are you saying in your last paragraph that I might be able to recover the download capability with, say, a really short program that can be downloaded "in between" the resets issuing from processor?

Not exactly. It's the job of the debug adapter (and its companion software) to get the target into a stable state, such that it can write your application to flash. The size of that application shouldn't matter. You as the user shouldn't have to worry about resets happening while the programming is taking place. That should all be taken care of by the debug adapter/software.

Exactly how the debug adapter/software gets the target into a stable state will vary between devices and the debug provider. In some cases it will involve placing instructions to disable the watchdog in SRAM, and executing them before trying to perform the flash write operation. Sometimes, if the target is stuck in a reset loop then the debug adapter/software may struggle to perform the operations it needs to to get the target into a stable state. The extent of this problem varies between different targets and debug solutions.

The other thing to be aware of is that if a mass-erase simply clears every bit in flash, then both security bits in the flash configuration field are being set to 1, which is a secure state. The mass-erase command has turned off flash security, but if you reset before writing a new application that disables flash security in the flash configuration field, you'll just end up in a secure state again. Note however that when you ask a particular debug adapter to perform a mass erase it could simply clear flash, or it could clear flash then modify the flash configuration field to unsecure the target across reboots.

With that in mind, let me rephrase the final paragraph from my previous response:

* If the device is secure and mass erase is disabled then it's probably a brick (unrecoverable).

* If the device is secure and mass erase is enabled then it should be recoverable.

* Performing a mass-erase will unsecure the device...

* ...BUT...some things can make the device unusable again pretty quickly (including reset loops, and cleared flash configuration fields)...

* ...SO...when recovering a secured device perform the mass erase, then get a known-good program onto it as soon as possible (before a reset).

Hopefully that answers your question?