#236 Cannot flash Kinetis Z parts

[Ramy]

I am using a Kinetis MK20DN512ZVLQ10 which is an earlier version of the MK20DN512VLQ10. Flashing the non-Z part works fine in OpenOCD 0.10, but when flashing the Z part, the following error occurs:
"Flash operation not possible in current run mode: SMC_PMSTAT: 0x0"

It looks like the code in the kinetis_check_run_mode function reads the SMC_PMSTAT register on the target device to check that it is in run mode. This register does not exist on the earlier revision K20 device, so pmstat is always 0 and OpenOCD refuses to program the device.

I have attempted to use earlier versions of OpenOCD which don't have this check, but they fail when trying to flash either device.

[Tomas Vanek]

Thanks for the report.

SMC_PMSTAT is checked because flashing in VLPR mode is not possible.
When I implemented this check, I did not know about "Initial Product Rev" (Z part).

RM reads that Z dev has a Mode Controller instead of SMC at 0x4007e000.
So to fix this problem correctly, we should introduce a new item in enum sysmodectrlr_type,
set it for KINETIS_K_SDID_K10_M100 and KINETIS_K_SDID_K20_M100 if REVID == 0 and detect VLPR from MC_PMCTRL RUNM bits.

Do you want to contribute such change?

[Martin Hierholzer]

I am having the same problem. I created a patch to fix this:
https://github.com/mhier/openocd/commit/521f516ec6874b5f9da379247015530fb5a122a4

This has been tested with a MK60DN512ZVMC10. Due to lack of hardware, I cannot test this with revision 2.x chips (i.e. without the Z). Also I am not using the VLPR mode, so I did not test whether the switch to normal run mode works.

[Tomas Vanek]

Martin,
thanks for working on this issue.
Could you please submit the patch to our gerrit at https://review.openocd.org
See https://openocd.org/doc/doxygen/html/patchguide.html for details.

IMO we should detect "Initial Product Rev" (Z part) more precisely.
I browsed Freescale docs and "Initial Product Rev" exists for
KINETIS_K_SDID_K10_M100, KINETIS_K_SDID_K20_M100, KINETIS_K_SDID_K30_M100, KINETIS_K_SDID_K40_M100, KINETIS_K_SDID_K60_M100 and also for K50 M100 never supported in OpenOCD

I found a doc relevant to SIM_SDID REVID
https://www.nxp.com/docs/en/engineering-bulletin/EB782.pdf
I would guess by mask set names that only revision number 1.0 (REVID 0) is "Initial Product Rev"

Also see a similar doc for K22F which doesn't have any "Initial Product Rev"
https://www.nxp.com/docs/en/engineering-bulletin/EB811.pdf
The lowest REVID is 1 so it looks like we can just check for REVID 0 to detect "Initial Product Rev".
Unfortunately Freescale doesn't publish revision lists of all Kinetis devices so my guess might be wrong. To be safe from a possible regression I would prefer checking for REVID 0 on the devices listed above.

[Tomas Vanek]

Martin,
you should also consider this:
KL devices have a FOPT option to run in VLPR mode on exit from reset.
Switching from VLPR to RUN mode is necessary for KL devices, because the device can be in VLPR mode after 'reset init' and without switching to RUN mode any flash programming fails.
Unlike KL devices, K device is always in RUN mode after reset! Hopefully there is nothing like "Initial Product Rev" in KL devices. Therefore the code for "Initial Product Rev" can simply fail with a message suggesting to issue 'reset init' when PM_STAT_VLPR is detected.

[Martin Hierholzer]

Thanks for the fast reply! I will submit this to Gerrit once I have addressed your first comments.

About the REVID: The interface switch was done between Revision 1.x and 2.x. This is described in this NXP document:

https://www.nxp.com.cn/docs/en/application-note/AN4445.pdf

My MK60 chip has the part number MK60DN512ZVMC10 and REVID = 7. The very first revisions 1.0 to 1.2 were not even called MK60 but PK60 but without a "Z" in the part number. The "Z" in the mask set obviously does not correspond to the "Z" in the part number at all. NXP made a fine mess here...

Still, the KL series should not be affected by my change at all. They seem to end up in the "Newer K-series or KL series MCU" branch of the if condition testing the KINETIS_SDID_K_SERIES_MASK.

Anyway, if only the KL series needs switching the VLPR to RUN mode, maybe we could just remove the entire check for the older K-series MCUs (first branch of the aforementioned if condition). This would eliminate the need to discriminate between the REVIDs at all. I would probably do that by introducing a new field in the kinetis_chip struct controlling whether kinetis_check_run_mode() shall check the pmstat at all.

Do you agree this may be the better approach? Or is it important to check also on K-series whether the MCU is in normal RUN mode for extra reliability?

[Tomas Vanek]

Thank for the pointer to AN4445. Now it's clear that my guess was wrong.

Still, the KL series should not be affected by my change at all.

Yes

Anyway, if only the KL series needs switching the VLPR to RUN mode, maybe we could just remove the entire check for the older K-series MCUs (first branch of the aforementioned if condition). This would eliminate the need to discriminate between the REVIDs at all.

K series doesn't need switching from VLPR to RUN as the device reset ensures RUN mode. Unfortunately they DO need VLPR check for the case when an user app switches to VLPR and user starts programming without issuing device reset (it's a bad practice although possible).
FTFE (or how Freescale named the flash module) in VLPR mode simply does not respond. No error returned. Some flash operations finish as they were successful - just the flash doesn't change.

The new code for switching K "Initial Product Rev" from VLPR to RUN is pretty similar to the existing code for K rev 2.x, so let's use it as you wrote in
https://github.com/mhier/openocd/commit/521f516ec6874b5f9da379247015530fb5a122a4

REVID detection itself is also correct, but should be limited to the devices I listed in
https://sourceforge.net/p/openocd/tickets/236/#2e60

And in the enum use KINETIS_MC instead of KINETIS_SMC_NONE, as we use MC instead of SMC

[Martin Hierholzer]

I submitted the patch to Gerrit:
https://review.openocd.org/c/openocd/+/7015

I hope I got your comments right :-)