#388 RESET/WDOG Loop Lockup with Kinetis MK22
I have developed a programmer application in Python for our products. The programmer has to program various things over various physical interfaces including images onto Microchip ATSAME70 family MCUs, Kinetis MK22 family MCUs and Altera FPGAs, using OpenOCD and an FTDI board behind the scenes. I have succeeded in getting the ATSAME70 MCUs and the Alteras programmed via OpenOCD. I can also program the MK22s via the FTDI board and OpenOCD, but only AFTER I have already programmed them once with a PE Micro MultiLink Universal adapter. However, I am unable to program pristine from the factory MK22s via the FTDI board and OpenOCD without this additional step and hardware expense.
I have nSRST and nTRST connected. I am using the ft232h.cfg file for my interface and the kx.cfg file for my target. When I connect OpenOCD to the MK22 MCU I get messages about the MCU being "probably locked-up in RESET/WDOG loop." The message also includes the suggestion to issue the "kinetis mdm halt' command or if SRST is connected and configured to use "reset halt." It says further that if the MCU cannot be halted to issue the "kinetis mdm mass_erase" command. None of these seem to help me out any.
When I issue "kinetis mdm halt" I get the message "Target not examined, reset NOT asserted!"
When I issue the "reset halt" command I get essentially the same messages and suggestions that I received when I first connected OpenOCD to the MCU.
When I issue the "kinetis mdm mass_erase" command I get a message telling me to press RESET (we don't have a reset button") and then it times out waiting for the reset button to be pressed. It goes on to suggest that I connect SRST (already connected) and use "reset_config srst_only" and retry. I type this in the telnet command line and then retry "kinetis mdm mass_erase". This time I do not get the press reset message and there is no timeout, but I still get the message "Target not examined, will not halt after reset!"
After all of these things (tried serially and individually), I still do not have most of the OpenOCD functionality available and I still cannot write an image to flash.
I am pretty new to OpenOCD and it's likely I'm just doing something wrong. I'm hoping one of you smart guys can tell me what it is that I'm doing wrong. Thanks. -Mike
Hi Mike,
unfortunately this is a known problem.
It is broken since merging https://review.openocd.org/c/openocd/+/6548
I proposed to revert this commit in https://review.openocd.org/c/openocd/+/6753
but no other maintainer voted for it.
You may try to compile a custom OpenOCD version with the proposed revert and it should be able to program Kinetis Kx series MCUs with empty flash.
Hello Tomas,
Thank you for your quick reply. I will try to accomplish the compile of the revert that you have suggested. I have never attempted to compile OpenOCD nor do I know how to obtain the reverted code, but I'll start learning.
I just learned that NXP offers a debug probe called MCU-LINK that only costs $12 that they claim works with OpenOCD. You don't happen to have any knowledge if this empty flash program problem is worked around by this combination , do you?
Thanks,
Mike
Thank you so much Tomas! I went back to the OpenOCD 0.10 binary and it fixed the problems (after I changed my interface cfg files to use the older syntax). Worst case, I could stick with version 0.10, but I have seen the changes thanks to the links you have included and they seem relatively simple and self contained, so I think I'll figure out how to compile OpenOCD and take version 0.12, make the necessary changes and recompile. Once again, thank you very much. You have been a life saver!
Good to hear that.
IIRC MCU-Link works as a CMSIS-DAP adapter. CMSIS-DAP generally works for Kinetis Kx series MCUs with empty flash but I didn't test MCU-Link - so you mileage may vary...
I have succeeded in making the reverts to 0.12 and succeeded in recompiling to an exe on Windows (11). However, the resulting exe has lost it's understanding of where the scripts directory is as the xpack binaries did. I have to either put the scripts in the same directory as the exe OR fully qualify the path to the scripts. I would rather not have to do either of these things for portability of where OpenOCD will reside. What do I need to do to recover the ability to just specify -f interface/... and -f target/...
Thank you,
Mike
You might want to explain how you built OpenOCD such that it ended up not being able to find scripts in the usual places?
I couldn't find a source that was an "official" detailed instructions on how to build OpenOCD on Windows. So I instead just went to google to try to find help. The one I ended up using was this https://medium.com/@burstaccessing/building-openocd-on-windows-ff625dc4fbb7. I tried several different websites giving instructions. This one seemed to work the best.
Prior to building OpenOCD on my own, I was using the xpack windows binaries for version 0.11. After extracting the binaries to a folder, I set up the windows PATH environment variable to point to the extracted folders bin directory so that I could use the OpenOCD command from anywhere (without changing directory to the bin folder). I found that even when using OpenOCD from "anywhere", simply specifying -f interface/... or -f target/... was enough for OpenOCD to find the cfg files in the scripts folder (scripts folder was at the same level as the bin folder). This was true regardless of which directory I started OpenOCD from. I was a little bit surprised by this but happy that it worked this way. I assumed it was a feature of OpenOCD but now I'm wondering if the people that made the binaries modified the source to make this happen.
At any rate, after following the instructions in the link provided, I ended up with a build of OpenOCD that ran. I set my PATH variable to point to this new OpenOCD bin folder and I could start OpenOCD from any console regardless of it's working dir, but now, just specifying -f interface/... or -f target/... was not able to find the cfg files. It works if I fully qualify the paths to the cfg files or if I put the files under the bin folder along with OpenOCD and change directory to the bin folder. Both of these aren't a great solution for me because in introduces some hardcoded path requirements to my application that I would rather not be there.
Having said all that, doing some further reading here https://openocd.org/doc/html/Running.html seems to indicate that on Windows, OpenOCD will additionally search in %APPDATA%/OpenOCD for scripts. I haven't been able to try this yet (I'm not at work right now), but if this is true and works, this will solve my problem and allow me to return to not needing hardcoded paths; At least in Windows... I also need to do this for Debian Linux (Raspberry Pi OS). I think there will be a similar solution in Linux though.
OpenOCD is in fact searching %APPDATA%/OpenOCD on windows for scripts. So that will work for me. Thanks.