Erich Styger Offers Tips for Getting a "Bricked" NXP Kinetis Board Back Up and Running Again

Engineer Erich Styger has shared a solution to the problem of "bricked" NXP Semiconductors Kinetis hardware, for when the anti-reverse engineering measures get a little overzealous — allowing otherwise-unusable hardware to be brought back to life.

"Modern MCUs like the NXP Kinetis have security features which prevent reverse engineering, but can ‘brick’ devices too," Styger explains. "Depending on the settings, it prevents read-out from the flash or reprogramming the device. While some of the protection is (mostly) not by-passable by design, in many case the devices looks like ‘bricked’ but still can be recovered."

Styger's advice applies only to that hardware which has been rendered unusable by its inner protection mechanisms, and not truly "bricked" devices that have suffered a true hardware failure. For those who aren't sure either way, following Styger's process is certainly worth a try before chucking a board in the bin — particularly in these times of mass component shortages.

"First: make sure you have some good and fast debug probes at hand," Styger writes. "The 'free and cheap' alternatives might work, but in my experience they are far less successful because [they are] not fast enough. I know that a good debug probe costs money, but it can be the difference between success and losing the device."

While the first step in Styger's recovery process is simply checking the debugging environment itself, followed by switching probes, it rapidly moves on: Attempting the built-in unlock function available with J-Link probes; using the a P&E probe to perform a full chip erase for emergency recovery; and, finally, having a crack at power glitching.

"The P&E debug probe includes a tool which talking constantly to the device during POR and can possibly recover a device that way," Sytger explains of the latter — relying on the speed of the debug probe to catch the processor unawares and halt it before the protection mechanism prevent its use can kick in.

Finally, and potentially the most useful of all, is Styger's advice to avoid getting into the situation in the first place: "Do not use ‘allow security’ for a J-Link device in your project settings," he writes. "The reason is: with ‘allow security’ it will write whatever you have set in your binary, and does not ‘fix’ possible security settings. So use ‘allow security’ only if you want to secure your device and you know what you are doing."

Styger's full write-up, with links to blog posts going into more detail on the steps, is available on the MCU on Eclipse website now.