Error: Target not examined yet

[ethyljoybadiang]

I got this using both Eclipse and VSCode. I am trying to deploy Hello_world on MAX78002EVKIT. I have actually tried it already, so as faceid, kws20_demo, etc. but suddenly I got this error in both Eclipse and VSCode.

Edit: I have tried turning off the firewall of my laptop but still the same error. So, I was told that it might be the network I am connected in because they close the unused ports for security reasons and as I checked netstat, ports 3000-7000 are really closed. Does it make sense? Also, I was asked what IP address/es to let them connect to the ports. Thank you!

[Jake-Carter]

Hi @ethyljoybadiang, considering you've been able to run some demos already this is most likely a symptom of low power lockout. See the documentation on Debug Limitations for more details. There is a recovery procedure you can attempt to recover the part.

Let me know if it works for you.

[Jake-Carter]

FYI the default port used to connect to OpenOCD from Eclipse is 3333. Same for VS Code's flash and flash & run tasks. The Cortex-Debug profile uses 50000 by default.

However, the connections are made through the localhost. So it's very rare (but not impossible) for the ports to be blocked.

[ethyljoybadiang]

Hi @ethyljoybadiang, considering you've been able to run some demos already this is most likely a symptom of low power lockout. See the documentation on Debug Limitations for more details. There is a recovery procedure you can attempt to recover the part.

Let me know if it works for you.

Okay, will try that now. I also tried running the examples from MAX78000 using my MAX78000FTHR board running it in Eclipse using a different laptop connected to a different network, same error showed.

[ethyljoybadiang]

I have tried it already (erasing the flash bank). It does not contain, fail.txt, but it is also not blank as it should be (as stated in 10).

[ethyljoybadiang]

So, this is the comparison after I did it.

[Jake-Carter]

The DETAILS.TXT file looks good.

In VS Code, can you paste the output of the "erase flash" task here?

Additionally, after running the "flash" or "flash & run" tasks there should be a flash.log file in your project. Can you attach it here as well?

This will give me some more detailed info to see what's going on.

[ethyljoybadiang]

Here is the flash.log file.
flash.log

[ethyljoybadiang]

Here is the output after the erase flash.

[ethyljoybadiang]

I tried building, flashing, and debugging it again after erase flash. I got this.

[Jake-Carter]

Thanks @ethyljoybadiang. OpenOCD is at least connecting to the micro in some capacity. Usually any low-power firmware lockout will throw the same error message as if your SWD cable is disconnected, or the board is powered off. Usually that's a "Cannot read IDR" message.

In this case, the primary error message is "Failed to read memory and, additionally, failed to find out where". This is usually a more esoteric problem and more difficult to debug. I wonder if you have been aware of the power-sequencing requirements for the MAX78002EVKIT? (See the quick-start guide here) It's possible that the chip could be damaged in some capacity, especially since you were able to run some demos on it before.

Do you remember the last demo you ran?

[ethyljoybadiang]

I once had wrong power sequencing but that was before I had trouble. Also, same errors show in the featherboard.

[ethyljoybadiang]

Can it be the ESD?

[ethyljoybadiang]

[Jake-Carter]

The PICO debugger can back-power into the board, which can exceed the absolute max ratings on some components (including the MAX78002) if the right power-up/power-down sequencing isn't followed. It looks like you've got the PICO debugger connected to the SWD port, right? And the Olimex connected to the RV JTAG port? (see Connecting Debug Adapters in the QSG).

It looks like the faceid_evkit demo is flashed. Is the demo actually running? (i.e. it's refreshing the screen with data from the camera?)

If the demo is running another thing you can try is holding the "RESET" button, then spamming the "erase flash" task in VS Code immediately after releasing reset. The debugger will not be able to connect to the micro while reset is held, but there is a 2 second delay placed at the beginning of the code to provide the debugger a window to connect to. If you hit this window (and the part is not damaged by the PICO back-powering), you should see a successful erase.

Additionally, can you run the following command in your VS Code terminal and paste the result?

openocd --version

It should match

Open On-Chip Debugger 0.11.0+dev-g56a818e4c (2023-10-09-16:14)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

Finally, please run the following command from your VS Code project. It will create an openocd_debug.log file with even more debug info. Please attach it to the ticket as well.

openocd -d3 -s "%MAXIM_PATH%/Tools/OpenOCD/scripts" -f "interface/cmsis-dap.cfg" -f "target/max78002.cfg" -c "init; reset halt" > openocd_debug.log 2>&1

[Jake-Carter]

Hi @ethyljoybadiang, any luck timing the hardware reset?

[ethyljoybadiang]

Hello! I am still trying to exhaust any software possibilities because the error goes both EVkit and fthrboard. I was told it might be a synthesis error, so I am trying to delve into that. Is it okay if I send my synthesized code if it works on yours?

[Jake-Carter]

Yes, please zip up your project and attach it to this ticket and I will test it on my board

[ethyljoybadiang]

Thank you.
banana.zip

[ethyljoybadiang]

The PICO debugger can back-power into the board, which can exceed the absolute max ratings on some components (including the MAX78002) if the right power-up/power-down sequencing isn't followed. It looks like you've got the PICO debugger connected to the SWD port, right? And the Olimex connected to the RV JTAG port? (see Connecting Debug Adapters in the QSG).

It looks like the faceid_evkit demo is flashed. Is the demo actually running? (i.e. it's refreshing the screen with data from the camera?)

If the demo is running another thing you can try is holding the "RESET" button, then spamming the "erase flash" task in VS Code immediately after releasing reset. The debugger will not be able to connect to the micro while reset is held, but there is a 2 second delay placed at the beginning of the code to provide the debugger a window to connect to. If you hit this window (and the part is not damaged by the PICO back-powering), you should see a successful erase.

Additionally, can you run the following command in your VS Code terminal and paste the result?

openocd --version

It should match

Open On-Chip Debugger 0.11.0+dev-g56a818e4c (2023-10-09-16:14)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

Finally, please run the following command from your VS Code project. It will create an openocd_debug.log file with even more debug info. Please attach it to the ticket as well.

openocd -d3 -s "%MAXIM_PATH%/Tools/OpenOCD/scripts" -f "interface/cmsis-dap.cfg" -f "target/max78002.cfg" -c "init; reset halt" > openocd_debug.log 2>&1

I actually did not do this, and have not really touched the kit since the last time. I just deleted the workspace and built another one..

Can you explain why? So, the chip is not destroyed?

[ethyljoybadiang]

Also, it only works on few of the examples in the sdk (Hello_world, faceid, imagenet)

[Jake-Carter]

Hi @ethyljoybadiang,

The banana known answer test you provided above works fine on my board as well.

Waiting...

*** CNN Inference Test banana ***

*** PASS ***

Approximate inference time: 3895 us

Classification results:
[ 199214] -> Class 0: 100.0%
[-244409] -> Class 1: 0.0%

If you send me one of the projects that's not working for you I will test it as well.

[ethyljoybadiang]

Ahhh yes thank you. It worked on my board as well after I deleted the eclipse-workspace. Thank you. This case is closed now.