OpenDAP error: Unable to connect wire for probe index 1

[Slaymaker]

I've programmed this MIMXRT1040-EVK with a few different examples--hello_world, bubble_peripheral, and finally adc_12b1msps_sar_interrupt. All have worked, and the final one is up and running, I can interact with it on the DAP COM port and get ADC readings.The OpenDAP drag-n-drop drive also shows up.

However, now when I try to connect to the board to download any of the above projects, I get:

Unable to connect wire for probe index 1.
Error: Wire Ack Fault - target connected?

What can I do to investigate and/or solve this, any ideas?

Many thanks,

Barrie

[Laurent137]

I also experienced this issue. I permanently solved it by removing the Wi-Fi/Bluetooth board that is connected through the M.2 connector (J8).

[expertsleepers]

Just jumping on this thread as I'm faced with the same issue with my MIMXRT1040-EVK. Yesterday it was fine; today I can't run or debug any projects. Not feeling great about adopting NXP for a new project at this point.

Reconnected to existing LinkServer process.

Connecting to probe 1 core 0 (using server started externally) reports:

'Ee(42). Could not connect to core.'

Retrying...

Reconnected to existing LinkServer process.

Server OK but no connection to probe 1 core 0 (after 3 attempts) - Ee(42). Could not connect to core.

============= SCRIPT: RT1040_connect.scp =============

RT1040 Connect Script

Error: Wire Ack Fault - target connected?

Error: Wire not connected

Error: Wire not connected

Disabling MPU

Error: Wire not connected

Error: Wire not connected

Configure FlexRAM for 256KB OC RAM, 128KB I-TCM, 128KB D-TCM

Error: Wire not connected

Error: Wire not connected

Error: Wire not connected

Finished

============= END SCRIPT =============================

Failed on connect: Ee(42). Could not connect to core.

No connection to chip's debug port

[Slaymaker]

@expertsleepers, don't let this color your NXP evaluation, I think it's specific to this EVK, and I'm guessing based on the lack of posts that it's not a highly used EVK. I may switch to a different one if this keeps happening and NXP doesn't respond.

[expertsleepers]

Thanks for the reply.

So, having found a Windows machine to work on I've downloaded the MCU Boot Utility.

I get an error when clicking "Load Unsigned Image":

"Please configure boot device via Flashloader first!"

I have no idea what it wants me to do - any hints?

[Slaymaker]

Not sure. Some things to double check (may all be obvious to you & already done, but just to be sure):

• Connect to the main MCU's USB port instead of the OpenDAP
• Configure the MCU for Serial Boot via the two Boot Mode switches on SW4 (0, 1 instead of the default 1, 0)
• Reset the MCU
• Check the Device Manager for two "vendor specified" USB devices
• Run the Boot Utility, it should automatically find the first of the two USB devices
• In the Boot Utility, connect to the board, this should download the necessary flashloader into the MCU's RAM

[expertsleepers]

None of this is obvious! I'm on day 2 of NXP MCUs and so far everything's quite bewildering. I'm finding the documentation great on detail but very lacking in high level overviews.

Anyway, taking all of what you said on board I've now managed to flash it with the Boot Utility and I'm finally able to debug again! Which is great. Many thanks.

[dayson · Accepted solution]

Update

I am now able to debug again. Yay! To get the debugging working again, I built the evkmimxrt1040_wifi_cli example project and flashed with the NXP MCU Boot Utility (maybe other projects will work, but I tried hello world and it didn't work). After manually flashing the wifi cli project I have been able to flash and debug the hello world example again. I haven't been able to make it break again (I'll report here when/how I do).

Steps

1: Build evkmimxrt1040_wifi_cli example project (listed in the wifi_examples group).

2: Open NXP MCU Boot Utility, connect to your MCU (not explained here).

3: Select the Application Image File you just built (file extension .axf). The location of mine is below, but yours will be elsewhere based on your MCUXpress workspace location.
C:\Users\user\Documents\MCUXpressoIDE_11.7.0_9198\workspace\evkmimxrt1040_wifi_cli\Debug\evkmimxrt1040_wifi_cli.axf.
Then choose "Generate Unsigned Bootable Image".

4: Finally, choose "Load Unsigned Image" on the page that appears after the image generation is complete. This takes a few minutes to flash...

Once flashed, I was able to reset my MCU, open MCUXpresso and start a debug session. Let me know if this works for you. I am still unsure why this worked. Any extra insight would be appreciated.

Thanks,
Ben

[mahmut]

I faced the exact same issue, and workaround from @dayson helped to be able to debug again. 

This is my first experience with NXP's products, and I must say that this is really bad. 

The entire debugging process is terrible. It will fail randomly and it's just quite bad experience. IDE based on Eclipse is 20 years old and it feels like I'm in 2000s again.

I tried to use external jlink debugger. Disconnected J9 and J10 as per user manual, but couldn't get it to work.

Anyways here's another piece of information that might help anyone who may have more insight into the whole situation. I flashed the board with iled_blinky example. I stop the debugging session and press reset button on board, D8 stays lit. Weird. Being newcomer to the world of NXP and having no idea what's happening I started debugging session again. I set few breakpoints to check if the pin is being toggled from within the firmware. It does, but D8 still stays lit. I flash the board with wifi_cli example, flash it again with iled_blinky, D8 now blinks. I do the reset, and the same things repeat. It stays lit. 

So, it looks like there are some issues with the CPU that are getting resolved after the board is flashed with wifi_cli. 

The entire situation with this eval board is really bad and I hope that NXP will do something about it. 

[expertsleepers]

I managed to get a J-Link debugger to work, but ended up in the same situation - after debugging and power cycling, the board was back in the bad state and wouldn't connect to the debugger.

This is very worrying. I have absolutely no faith that if I designed a product using a RT1040 that I'd actually be able to develop on it.

[mahmut]

So, it's not the debugger then. Can you also try to reproduce issue I mentioned with iled_blinky example, it might help someone to make some sense out of this? 

[expertsleepers]

I'll have a go.

In the meantime NXP support replied to my case, and offered this link:

https://mcuoneclipse.com/2019/01/02/regaining-debug-access-of-nxp-i-mx-rt1064-evk-executing-wfi/

So clearly this is a wider issue.

Unfortunately they didn't offer any actual solution.

[expertsleepers]

It is very disappointing, especially as you say for people like ourselves for whom this is their first experience with NXP.

I raised a support ticket on March 22nd. I have yet to receive a reply.

[Slaymaker]

I followed your process (thanks for the NXP MCU Boot Utility instructions. I had used it yesterday to erase the NOR--I think--but was baffled by its iconoclastic UI, lol). As with your experience, flashing the hello_world demo via the Boot Utility did not rescue the board (though the demo ran fine).

I hadn't build the wifi demos into my SDK, so I built a demo that I had previously run via the OpenDAP debugger, the bubble_peripheral, and flashed it with the Boot Utility. That seems to have reconfigured whatever was broken in the first place.

Then I got a debugging protocol error popup (Failed to read memory--don't recall more details), and the board re-entered the same broken state. Using the MCU Boot Utility with that same project fixed it again. Urgh.

I then debugged the demo app that I was playing with when the debugging link broke, adc_12b1msps_sar_interrupt, and that worked fine. I the went back to the bubble_peripheral and it also worked fine, now I'm back to the adc_12b1msps_sar_interrupt and it's running fine.

No IDE debugging protocol error popups thus far.

My best guess based on these behaviors is that there's some sort of race condition when debugging that causes the RT1040's SWD interface to get confused, and the first sign in this morning's case was the memory read error. No idea why it stays confused, but I'm really  glad @dayson found the general process to rescue the board.

More news as it happens.

We (me, @dayson, @expertsleepers, and anyone else who experiences this) should all open trouble tickets on this board--I think there is a defect in the processor or board support package (perhaps the suspected race condition, or a stray stale pointer) that triggers this.

[Slaymaker]

Update: I tried erasing the NOR via JayHeng's NXP-MCUBootUtility to no avail (I did this in the very unlikely case that it was some sort of CPU clock issue, or other basic configuration incompatibility).

Next Step: I've ordered another eval board and will see if I can see any differences, but this is board is so complex and I know so little about this debug interface and what might be wrong with the MCU's debug pins (which I'm guessing are misconfigured / blown), that I'm not able to dig in with a logic analyzer or scope given the time available.

[dayson]

I am also seeing this. Trying to work it out, will post here if I figure it out.