Cannot connect to i.MX8M M7 core using openocd on Windows

[Primářek]

Hello

I am trying to connect to a M7 core on a MIMX8ML8CVNKZ processor using openocd through a FTDI chip. I have followed the tutorial to replace the standard FTDI driver with the WinUSB one using ZADIQ and I get some response from the board. However I get the "examination failed" error. Here is the log from openocd.exe:

Open On-Chip Debugger 0.11.0-rc2+dev-00044-g8340bb0 (2021-06-02-17:29)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

Info : Hardware thread awareness created

Info : clock speed 1000 kHz

Info : JTAG tap: imx8mm.cpu tap/device found: 0x5ba00477 (mfg: 0x23b (ARM Ltd), part: 0xba00, ver: 0x5)

Info : DAP transaction stalled (WAIT) - slowing down

Error: JTAG-DP STICKY ERROR

Error: imx8mm.a53.0: examination failed

Warn : target imx8mm.a53.0 examination failed

Info : starting gdb server for imx8mm.a53.0 on 3333

Info : Listening on port 3333 for gdb connections

Info : starting gdb server for imx8mm.m4 on 3334

Info : Listening on port 3334 for gdb connections

Info : Deferring arp_examine of imx8mm.m4

Info : Use arp_examine command to examine it manually!

Error: The 'gdb_report_data_abort' command must be used before 'init'.

I am using a configuration script provided from tcl github. While I doubted the "imx8mm.m4" parts of the script given that my chip has a M7 core, my colleague who uses Linux was able to succesfully connect and debug the M7 core using the exact same configuration.

The error changes when I hold reset or powerdown the board. Along with "tap/device found" information, this shows that the connection is at least partially working.  This suggests that the error is somewher in my Windows installation. While I did find similar issues on the internet, including this forum, I failed to find a solution that would work for my problem.

Would it be possible to provide suggestions as to what could be the cause of this issue?

Thank you in advance.

[Primářek]

I was able to found the issue. In case someone other encounters the same problem the issue was that default code uploaded in the main cores somehow disabled the M7 so that it was unable to be connected to. Therefore the solution was to start the uboot menu of the main cores through their serial terminal and upload a "hello_world" example fot the M7 core. This started the core and after that, the OpenOCD and GDB were both able to make a stable connection.