AnsweredAssumed Answered

MK21FN1M0V12 locked

Question asked by olivier capron on Mar 15, 2017
Latest reply on Mar 16, 2017 by Kerry Zhou

We have locked several MK21FN1M0V12 devices because of a bad writing in internal flash. The Flash Configuration Field has been improperly set, resulting in the chip security being enabled.
We are working on the board with CodeWarrior for MCU v10.6 running on Windows.
We have tried several things but nothing succeeded. Here is a summary:

  • Connect a PE micro multilink device to the board and enable the "always mass erase" feature when setting the CodeWarrior connection. Everytime we try to debug, an error pop-up indicates that the connection fails
  • Define a mass erase task in the CodeWarrior "flash programmer" utility, same thing happens
  • Try the same with a JLink probe. This does not work either
  • Use JLink Commander. This is the most interesting part:
    • upon each connection, the tool detects the target is in secure mode and attempts to unlock it in a loop. It fails with a timeout error on halting the core
    • still, the tool connects to the target. some info can be retrieved (eg with hwinfo command), connection is OK but debugging is, of course, impossible
    • running the "unlock kinetis" command reports "OK" but nothing happens then (eg running "erase" still does not work, the tool complains the core is secure...)
    • reading the MDM-AP status register works and returns status 0x00000027 (this confirms mass erase is enabled, but also that the chip remains in reset state)
      to read it:
      - swdwritedp 2 0x01000000 // selects DAP #1
      - swdreadap 0 // dummy read
      - swdreadap 0 // returns 0x27
    • writing 1 to the "Flash Mass Erase" bit of the MDM-AP control register does nothing
      to do so:
      - swdwritedp 2 0x01000000 // selects DAP #1
      - swdwriteap 1 1
      no error is reported but nothing happens. Reading the MDM-AP status register does not show any difference

Since Mass Erase is still enabled, it should be possible, theoretically, to reset the FCF.
It seems it fails because the core is in a "reboot" loop since garbage has been written to flash (invalid code and/or  bad stack pointer etc). Could it be that the procedure fails because the core cannot be halted?
Finally, there is no "reset" button on the board. Would a reset button have helped here?

Thanks and best regards.

Outcomes