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. --- ** [tickets:#388] RESET/WDOG Loop Lockup with Kinetis MK22** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Mar 22, 2023 12:17 AM UTC by Mike Aoun **Last Updated:** Sun Mar 26, 2023 10:31 AM UTC **Owner:** nobody 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 --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
