Utility for erasing difficult FRDM Kinetis boards

[pgo]

We use a large number of FRDM-K20 boards in our lab classes.  Occasionally we have had them become un-programmable  due to software errors or interrupted programming tasks.

If the chip has been actually secured in one of the un-recoverable modes then there is not much you can do about it.  More often it is due to another reason such as:

• Programming of the FOPT location to disable the RESET pin
• Software disabling of the SWD-DATA or SWD-CLK pins
• Programming of the low-power modes
• Combinations of the above

In the above cases the P&E OpenSDA programmer or USBDM has problems re-programming the chip.

To cope with this I have produced a small program that can be downloaded to the board to more aggressively erase the target.

This is available from http://sourceforge.net/projects/usbdm/files/Version%204.10.6/Software/MassEraseKinetisFRDM.zip/downl...

bye

ReadMe.txt from download

==== What is it =====
This is a utility to mass erase the TARGET chip on a FRDM Kinetis board.  It is intended
to be quite aggressive in attempting to do this and may be useful for erasing targets that have
become unusable due to the following reasons:

- Programming of the FOPT location to disable the RESET pin
- Software disabling of the SWD-DATA or SWD-CLK pins
- Programming of the low-power modes
- Combinations of the above

Doing any of the above may result in the on-board P&E debugger being unable to re-program the target chip.
The current version of the USBDM software also find this difficult but the next version will incorporate
this option.

It can also be used with external chips if the 20-pin SWD connector is populated on the FRDM board.

NOTE:
This does not allow permanently secured chips to be unsecured.  Once you've done that it's all over :smileyhappy:

===== How it works =====
Once the firmware is programmed to the debugger chip and the board rebooted the debugger will sit in a tight
loop attempting to use software reset commands to force the target chip into a reset state. This is a bit of
a complicated process involving connecting to the target, enabling the debugger interface on the target and
then sending various commands to force the chip into reset.
Normally this process won't work if your have one of the problems listed above.  However, there is a small
window of opportunity during power-on of the chip where it may work - providing it's done fast enough.
Obviously this then requires you to be able to power-on the target without upsetting the debugger interface.
This requires a link on the FRDM board to be cut and replaced by a manual jumper.

After successfully connecting the debugger will then mass erase the target.

The debugger firmware is based on a stripped down version of USBDM.

===== PREREQUISITES =====
** A lightly modified FRDM board.
   The reqired modifications are:
   - Cutting a link on the FRDM board and replacing with a manual jumper.
   - Removing associated resistors in some cases (0R & 10R)
    Board type  | Jumper to cut
    ===========================
     FRDM-KE02Z |   J3 also remove R11,R12
     FRDM-KL02Z |   J4 also remove R27
     FRDM-KL05Z |   J4 also remove R27
     FRDM-KL25Z |   J4
     FRDM-KL46Z |   J17 also remove R1,R2

   The manual jumper can be used to power the target in normal use.

** A wire jumper lead for use when erasing the board - for some reason using a jumper is unreliable.

=====  METHOD =====
The attached SREC file is intended to be programmed to the MK20 debugger chip on a FRDM board (Not
the target chip!)  This can be done in the following manner:

* While holding the RESET switch pressed, plug in the FRDM board using the OpenSDA USB connector.
* The FRDM board will then appear as a USB drive.
* Drag the .sx file to the drive to program it to the debugger processor (small MKL20DX128 chip)

===== Doing a Mass erase ====
The following sequence should result in the target chip being mass erased:

* Remove the jumper added above so that the target is not powered.
* Plug in the board using the OpenSDA USB connector.
* The green LED on the board should be flashing at a fast rate with roughly equal on and off times.
  The debugger is now trying to connect to the target
* Close the power jumper pins (see above) using a JUMPER LEAD (not a jumper block).  I have no real idea why a
  jumper block does not work reliably.  When testing I have used a lead or an external switch - they both worked
  about 90% of the time on my test case.  Using a small jumper block was much less often successful.
* A few moments later the green LED should change to a flashing pattern of long-on, short-off.  This indicates
  that the mass erase has completed successfully.
  If the pattern changes to long-off, short-on then the process failed and should be repeated from the first step.

[quevedo]

This app works perfectly, but I would like to point that ff I power on the board without the jumper for powering the target processor, OpenSDA enters Bootloader mode, even if reset button is not pressed. Thus, OpenSDA will not execute the mass eraser app because it starts executing the bootloader program.

When running the app, one needs to keep the target power jumper on while connecting the board to USB, and only after that, power on target can be cycled off and on. I did that, and then the app worked.

[pgo]

Hi Antonio,

I rechecked my board and it boots correctly with the target power disconnected.  The Pull-up for the reset line is connected to P3V3 which I would expect to be powered even if the target is not.  There may be some variation with board version? Also, have you modified any of the other jumpers? (Tested with a FRDM-KL25Z).

There is one scenario where it would be undesirable to have the target power on when plugging in - but it is unlikely:

• RESET configured as an GPIO
• RESET is driven low by the target (can the RESET be an output?)

This could result in the board being forced into bootloader mode by the target chip - maybe...

bye

PS. Tried the above scenario and it did keep the debugger in Bootloader mode.

[quevedo]

Hi,

I am using FRDM-KL25 boards, revision E (not D). In this revision, there is no cut-trace on J4, and there are 2 resistors in paralell with this jumper: R73 (0-Ohm) and R81 (10-Ohm). I had to remove these resistors and solder the jumper pins, but this should not be an issue. I noticed that RevE has a jumper (J14) that can isolate target's RESET line from the rest of the SDA_RST_TGTMCU line. Anyway, this jumper is not populated, but it has a cut-trace, and it was not modified.

If we consider J14 as a simple connection, the circuits connected to SDA_RST_TGTMCU line are the same for both revisions. I do not believe that the problem would be target RESET configured as an GPIO output driven low, because having the targed powered on when plugging in had no problems at all: OpenSDA LED started blinking fast, and then I removed the jumper wire and re-connected it; then target was erased. Host processor entered bootloader when I had target power OFF, not ON.

Maybe there was a change in bootloader program for revision E, and there is a bug?

I will get one of the previously bricked boards at the teaching lab, and I will follow logic level on SDA_RST_TGTMCU line when I power on the board. Then I will post the results.

Cheers,

Antonio

P.S. The unbricked boards are on use now. I have a RevD board with a disconnection jumper J4, and when target power is off, the board loads my debugger app normally, instead of bootloader. Maybe it is a bug on bootloader version shipped with RevE boards, since RevD works nicely. I still want to check on logic levels for SDA_RST_TGTMCU on a RevE board.