bricked my MK20DX128XXX5 when updating SDA firmware via JLink

[biosbob]

some background:

i have a FRDM-K64F board that exhibited the issue described here:  https://community.nxp.com/t5/Kinetis-Microcontrollers/Freedom-OpenSDA-Firmware-Issues-Reported-on-Wi...

i then went to the SDA download site and selected FRDM-K64F (https://www.nxp.com/design/software/development-software/sensor-toolbox-sensor-development-ecosystem...)

after downloading the .bin file for the SDA v2.2 bootloader (and then putting my FRDM-K64F into BOOTLOADER mode by holding down the button, etc), i copied the .bin file to the board....  after plugging my board back-in, it correctly enumerated as FRDM-K64F....

thinking i was home free, i then tried to debug an example from the FRDM-K64F SDK inside of MCUXpresso using the LinkServer probes....  no luck here, however; couldn't load the board (though it did seem to think something was there)....

at this point, i used my segger debug adapter to directly program the downloaded SDA 2.2 .bin file into the MK20....  following the instructions detailed in the first link above, i presumably erased and then re-flashed the MK20....

now, however, the FRDM-K64F doesn't enumerate all; and pushing reset causing no reaction....

i then tried re-connecting to the MK20 through my segger probe -- but now i couldn't connect all, due to what appears to be "wrong" settings at 0x400 which are locking out access....

i have not looked through the image, but somehow the contents at 0x400  (usually 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFF, 0xFFFFFFFE from my experience with other kinetis MCUs) are "wrong"....

several questions, then:

1) i have another FRDM-K64F on order, and i don't want to make some mistake twice....  could someone comment on whether i missed something here

2) is there *ANY WAY* to recover the MK20 -- even by mass erasing its flash using my jlink probe

[biosbob]

i'll download and try KDS....  and just to clear, you want me to program the empty main() on the K64 (or on the K20)???

[ErichStyger]

program the K20, because that's the one you want to program. The K20 is unfortunately not supported by MCUXpresso.

[biosbob]

i just tried doing the "unlock, erase, loadbin" in one jlink session; everything appears to go correctly....

but then when unplugged/replugged my FRDM-K64F into my PC, the board did not enumerate....  in fact, the board appears totally dead -- no power LED, etc....

[ErichStyger · Accepted solution]

Have you tried to program the K64F directly, using the debug header on the board?

I mean you don't really need the K20 on the board to program the K64F, you can do it directly with your J-Link EDU.

[biosbob]

i thought i tried this already, but will give it another shot....

for now, i'll assume the SDA part of the board is "dead"; i'll power the K64 through my bench supply....

do i need to cut any traces on the FRDM-K64F board???

[ErichStyger]

btw, you might find another article I wrote useful on that topic:

https://mcuoneclipse.com/2016/06/26/how-to-recover-the-opensda-v2-x-bootloader/

just in case

[ErichStyger]

No, you don't have to do cut anything (unless the K20 would somehow interfere, which I don't think in that case).

Erich

[ErichStyger]

2) is there *ANY WAY* to recover the MK20 -- even by mass erasing its flash using my jlink probe

If 'mass erase' is disabled, then you won't be out of luck, see https://mcuoneclipse.com/2012/11/04/how-not-to-secure-my-microcontroller/comment-page-1/

You could try the 'unlock' command, see https://mcuoneclipse.com/2014/10/05/unlocking-and-erasing-flash-with-segger-j-link/

I had good success with the PEMICRO debug probe using a power glitch approach, see https://mcuoneclipse.com/2021/05/20/recovering-cortex-m-microcontroller-with-a-power-glitch/

I hope this helps,

Erich

[ErichStyger]

as for regaining access to the K20, this one might be helpful:

https://mcuoneclipse.com/2022/06/16/resurrecting-bricked-nxp-kinetis-devices/

[ErichStyger]

That bin file looks ok, with still mass erase enabled:

So if you have 0xfffff on your K20 there, you definitely have a problem. But I don't think so, if you really flashed that part. One issue I have seen in the past with the 'erase' command with a J-Link device setting for 'allow security', then it indeed erases it to 0xffff, and if you do a reset prior flashing the 'good' values, then you can have a problem. I suspect I had this as a problem at least in one case, but I'm not willing to experiment around this for obvious reasons.

What message do you get from your J-Link if you try to connect?

I hope this helps,

Erich

[biosbob]

i was able to successfully "unsecure" the MK20 and then perform an erase....

but when i tried to load the .bin file (using jlink-lite), it failed with a simple "cannot connect to target" message....

i then tried to establish the connection using jlink commander, which produced the following errors (which, among other things, references protection at 0x400)....

SEGGER J-Link Commander V6.88a (Compiled Nov 18 2020 15:10:56)
DLL version V6.88a, compiled Nov 18 2020 15:09:23Connecting to J-Link via USB...O.K.
Firmware: J-Link EDU Mini V1 compiled Nov 12 2020 13:31:42
Hardware version: V1.00
S/N: 801029555
License(s): FlashBP, GDB
VTref=3.288VType "connect" to establish a target connection, '?' for help
J-Link>connect
Please specify device / core. <Default>: MK20DX128XXX5
Type '?' for selection dialog
Device>
Please specify target interface:
  J) JTAG (Default)
  S) SWD
  T) cJTAG
TIF>S
Specify target interface speed [kHz]. <Default>: 4000 kHz
Speed>
Device "MK20DX128XXX5" selected.Connecting to target via SWD
InitTarget()
Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash.
Executing default behavior previously saved in the registry.
Skipping unsecure.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x001C0000)
Iterating through AP map to find AHB-AP to use
AP[0]: Skipped. Could not read CPUID register
AP[1]: Skipped. Not an AHB-AP
InitTarget()
Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash.
Executing default behavior previously saved in the registry.
Skipping unsecure.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x001C0000)
Iterating through AP map to find AHB-AP to use
AP[0]: Skipped. Could not read CPUID register
AP[1]: Skipped. Not an AHB-AP****** Error: Could not find core in Coresight setupInitTarget()
Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash.
Executing default behavior previously saved in the registry.
Skipping unsecure.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x001C0000)
Iterating through AP map to find AHB-AP to use
AP[0]: Skipped. Could not read CPUID register
AP[1]: Skipped. Not an AHB-AP
InitTarget()
Protection bytes in flash at addr. 0x400 - 0x40F indicate that readout protection is set.
For debugger connection the device needs to be unsecured.
Note: Unsecuring will trigger a mass erase of the internal flash.
Executing default behavior previously saved in the registry.
Skipping unsecure.
Found SW-DP with ID 0x2BA01477
DPIDR: 0x2BA01477
Scanning AP map to find all available APs
AP[2]: Stopped AP scan as end of AP map has been reached
AP[0]: AHB-AP (IDR: 0x24770011)
AP[1]: JTAG-AP (IDR: 0x001C0000)
Iterating through AP map to find AHB-AP to use
AP[0]: Skipped. Could not read CPUID register
AP[1]: Skipped. Not an AHB-AP****** Error: Could not find core in Coresight setupCannot connect to target.
J-Link>

do i need to do the "unsecure, erase, loadbin" in one jlink session????   note that the above session only attempted to connect....

[ErichStyger]

Can you program just an 'empty' main() to the device, say using KDS?

From the error messages I'm not 100% sure if it might be problem with your setup. Using KDS seems a much easier way to me to verify if you still can access the device.