MCUxpresso error Ee(42) Could not connect to core. Fails on Windows 10 - works on OsX

[jtmiii]

Trying to get the demo lab setup for the eIQ virtual event. Started with a new RT1060 EVK board. Installed the camera, lcd display and then wanted to do basic checkout before installing any of the lab demos. Board powers up from USB connection and blinky runs (green user led blinks) - first test, load hello world to prove that the board is communicating.

Board fails with the folowing errors displayed in MCUxpresso:

Dialog box message:
Error in final launch sequence:

Failed to execute MI command:
-target-select extended-remote | crt_emu_cm_redlink -msg-port=51856 -g -mi -2 -pMIMXRT1062xxxxA -vendor=NXP   --reset= -ProbeHandle=1 -CoreIndex=0 -cache=disable --flash-driver= -x C:/Users/James/Documents/MCUXpressoIDE_11.0.0_2516/eIQworkspace/evkmimxrt1060_hello_world/Debug --flash-dir C:/nxp/MCUXpressoIDE_11.0.0_2516/ide/plugins/com.nxp.mcuxpresso.tools.bin.win32_11.0.0.201905221151/binaries/Flash --flash-dir C:/Users/James/Documents/MCUXpressoIDE_11.0.0_2516/eIQworkspace/.mcuxpressoide_packages_support/MIMXRT1062xxxxA_support/Flash --telnet 3330 --no-packed
Error message from debugger back end:
Remote communication error.  Target disconnected.: Success.
Failed to execute MI command:
-target-select extended-remote | crt_emu_cm_redlink -msg-port=51856 -g -mi -2 -pMIMXRT1062xxxxA -vendor=NXP   --reset= -ProbeHandle=1 -CoreIndex=0 -cache=disable --flash-driver= -x C:/Users/James/Documents/MCUXpressoIDE_11.0.0_2516/eIQworkspace/evkmimxrt1060_hello_world/Debug --flash-dir C:/nxp/MCUXpressoIDE_11.0.0_2516/ide/plugins/com.nxp.mcuxpresso.tools.bin.win32_11.0.0.201905221151/binaries/Flash --flash-dir C:/Users/James/Documents/MCUXpressoIDE_11.0.0_2516/eIQworkspace/.mcuxpressoide_packages_support/MIMXRT1062xxxxA_support/Flash --telnet 3330 --no-packed
Error message from debugger back end:
Remote communication error.  Target disconnected.: Success.

MCUxpresso console window:

MCUXpresso IDE RedlinkMulti Driver v11.0 (May 22 2019 13:46:40 - crt_emu_cm_redlink build 6)
Found chip XML file in C:/Users/James/Documents/MCUXpressoIDE_11.0.0_2516/eIQworkspace/evkmimxrt1060_hello_world/Debug\MIMXRT1062xxxxA.xml
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.
Failed on connect: Ee(42). Could not connect to core.
No connection to chip's debug port

This was with MCUxpresso build "MCUXpresso IDE v11.0.0 [Build 2516] [2019-06-05]" on a Windows 10 Core I7.

SDK build version: RT1060 - 2.6.2 238 2919-07-11 with required eIQ mods as described in  https://community.nxp.com/docs/DOC-344227 

Reinstalled MCUxpresso over the existing install as this was indicated to solve the problem by one of the community notes. This left MCUxpresso in a state where it would not start correctly. (side note: get you installer guys to fix there installer) .

Next uninstalled MCUxcpresso using control panel/programs/... (uninstaller left the mcu directories however - which were then deleted) Then reinstalled MCUxpresso again. Starts correctly, still has the above problem. Possible driver problem?

Considered a possible USB port problem - moved to new USB port - same problem. No USB hubs involved. Also tried both USB3 and USB2 ports. No difference.

Installed MCUxpresso build v11.0.0 [Build 2516] [2019-06-05] on to my Mac/OsX system. Installed newly downloaded SDK for RT1060 (build 238 2019-07-11) from the NXP website. Loaded the hello world demo - build, selected debug - app built

and loaded and ran as it should.

What is the problem with the windows version of MCUxpresso?

Thank you.

[AJGriggs]

Same problem here with older MIMXRT1020.
Latest install of McuXpresso on Unbuntu 20.04.

.....

MCUXpresso IDE RedlinkMulti Driver v11.3 (Jan 11 2021 16:44:35 - crt_emu_cm_redlink build 9)
Found chip XML file in /home/griggs/Code/Nxp/evkmimxrt1020_freertos_hello/Debug/MIMXRT1021xxxxx.xml
( 5) Remote configuration complete
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.
Failed on connect: Ee(42). Could not connect to core.

...

Please help me resolve this.

Thanks,

A. J. Griggs

[vageeshpanditha]

Hi,

I am also facing similar issue. Attached screenshot.

[vageeshpanditha]

Even facing issue in mass erase also.

[ChrisN]

Juan Carlos,

I went through the steps and (of course) the problem persists. Because it's got nothing to do with the board or the microcontroller, it has been a problem with the debug interface and MCUXpresso since NXP switched to LPC-Link2 that appears on some Windows installations like mine. I have the exact same problem on this machine with any of the NXP boards I have here (at least 10 different ones: LPC54xxx, i.MX RT, KW36, others) and with the LPC-Link2 standalone debug interface. The original LPC-Link always worked fine. Further proof:

• Using another Windows computer - no issue with any board and CMSIS-DAP, so the boards and microcontrollers are fine!
• Using J-Link firmware for on-board debug interface (where available, not many boards) or standalone J-Link debugger - no issue with any board
• On the "problem computer", using not MCUXpresso but Keil uVision debugger with on-board CMSIS-DAP: no issue :smileyalert:

I wonder how many more years it will take NXP to admit that on some Windows computers there is a deep-rooted problem with the USB connection to LPC-Link2-based CMSIS-DAP debug interface and how MCUXpresso is using it.

The problem even persists, if you run Linux under VMware on the Windows "problem computer" host and use the Linux version of MCUXpresso and connect to CMSIS-DAP through guest USB emulation, forwarded to the host USB port!

As I said, the issue is deep-rooted and there is no fix. Don't try to look for a fix on the board level - MCU, flash, power supply, this is all chasing ghosts and has nothing to do with the issue. I've tried it all.

[ChrisN]

Juan Carlos,

Since I am having the same problem as James, I just tried your suggestion. The "Probe discovered" dialog looks just like yours, with LPC-Link2 detected:

but then:

Latest MCUXpresso 11.0.1.

Regards,

Chris

[jc_pacheco]

Chris,

Can you please try to mass erase the flash booting from the fuses:

1. Configure the board to boot from fuses(SW7: 0000, see reply https://community.nxp.com/message/1205879?commentID=1205879&et=watches.email.thread#comment-1197394)

2. Power up the board

3. Open MCUXpresso and select mass erase

4. Wait until it's mass erased

5. Disconnect board

6. Configure the board to boot from flash (SW7:0010)

7. Flash your board as usual

-JC

[jc_pacheco]

James,

Have you tried using the debugging probe in LPC-Link2 mode instead of DAPLink OpenSDA mode? See Chapter 4 from RT1060_BriefOverview_v102.pdf. Place a jumper in J42 to set the debug probe in LPC-Link2 compatibility mode, and configure J1 to use power source from J9 or J2 (this mode requires the board to be powered externally).

[jtmiii]

Update to the last two posts... unfortunately since the eIQ virtual event was eclipsed by this problem I have had to move back to other tasks... however the problem still needs resolution since it is impacting both the RT1060 and the RT1064 boards on my Windows 10 system. The RT1064 chip is the one we are planning to use for our product, so this still remains an issue. I am able to proceed by working from my OSX or Linux systems, however a Windows solution is needed long term.

As for the two suggestions above, I have downloaded and installed the drivers referenced in the post by Victor. This had already been done, but to ensure that I had the latest available, I re-downloaded the drivers and re-installed. No change in the behaviour.

As for the quality of power, I had considered this and as a result had eliminated any USB hubs which may not have had sufficient power to source for the board. As an additional investigation, to eliminate this power issue as a possible source of the problem, I attached the board to a lab grade power supply that would provide measurements of both the voltage and current being supplied to the board. The following observations were made:

The voltage setting on the power supply was set at 5.05V and the current setting was sufficiently high that the power supply was not current limited. The voltage was verified using a calibrated VOM (do we still call DMMs VOMs?) 

The board was configured with J1 pins set for power from J2 (pins 1-2). Actuating the power slide switch confirmed that no other power source was providing power (the USB power). 

With the blinky application loaded into the board, Voltage unchanged at 5.05V and current was 0.11A.  

Using my OSX system running MCUxpresso, I was able to reload the blinky application, no change in voltage or current.

Loading the emwin slideshow application, the voltage was unchanged, but current increased to 0.30A which is reasonable since the application enables the touch display.

Reloading the blinky application, voltage was unchanged at 5.05V and current returned to 0.11A which is as expected.

Given the power supply can source 3A current, these fractional amp measurements are believable. Also the power supply did not indicate current limiting during the entire investigation. 

I then attempted to load an application using my Windows 10 system, MCUxpresso and the same two applications. The USB cable, power connections and power supply were not changed. Only the connection of the USB cable to the Windows system. The problem reported above in detail was still present - the same error messages were reported by MCUxpresso. 

I believe we can eliminate power to the board as a possible source of this issue.

[lpcxpresso_supp]

My suspicion is that you are suffering from insufficient power - debugging can often trigger problems if your supply is marginal. On the assumption that you are powering your board via the onboard debug probe USB connector connected directly to a USB port on your PC, try connecting via a powered hub instead. Or else power via a separate power supply or via the "target USB" USB connector.

For more information on using your board with MCUXpresso IDE, I would also strongly recommend that you read the blog article we have published in the MCUXpresso IDE forum : https://community.nxp.com/community/mcuxpresso/mcuxpresso-ide/blog/2019/01/23/overview-of-using-the-... 

Regards,

MCUXpresso IDE Support

[jtmiii]

Switch SW7 was set to 0010 (factory default - unchanged) out of the box. Checked this before
I started - since I have seen other boards in the past arrive with non-default options set
(won't name vendor - not NXP).

Moved SW7 to be 0000 (all switches toward center of the board), did power on reset
to the board and started MCUxpresso.

Attempted to load unmodified emwin slide show application (which I have been able to load
from both MAC OSX and Linux Ubuntu) and received the following error messages (which are
the same as I had been receiving on windows).

As additional information, the Windows system I have has 8 USB ports on the mother board.
4 USB 2.0 and 4 USB 3.0 - in an attempt to eliminate either a bad port or incompatibility
between the board and the USB version, I have repeated this with the 1060 board connected
to each port. No change.

Dialog boxes from the reported error:

Top:

Middle:

Bottom:

Console:

[senR]

Had faced the similar problem with the following error.

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

No connection to chip's debug port

etc.

It was not the Firmware update or anything as I initially thought. It is simply the position of jumper pin setting. Check the user guide

You will find the setting of J23 pin setting. Default position is 1-2. It needs to be 5-5. Also, at the backside of the board, there are 4 SW. Its sequence should be OFF ON ON OFF.

You also need to change the J2 jumper pin set to 1-2 if there is SDIO error (problem with the wifi module).  

With the above change of jumper pin setting I am using without problem.

Reference user guide (HW)

https://www.mouser.com/pdfdocs/NXP_MIMXRT1020-EVK_UG.pdf

https://www.azurewave.com/img/nxp/AW-NM191NF-EVB_v02_User%20Guide_20210809.pdf

[victorjimenez]

Hello James,

I'm sorry to hear that our previous recommendations didn't work for you. Thanks for attaching the dialog boxes from the reported error.

On the OpenSDA page of the RT1060-EVK (link) we mentioned that if you have not installed already an Arm IDE toolchain, you need to download and install the corresponding drivers, which in your case are the ARM CMSIS-DAP serial drivers. Could you please install these drivers on your Windows PC? Once you install the drivers, you need to restart your computer. Please, let me know the results on your side.

By this time, we reported this behavior with the corresponding team and they are already working on this. Sorry for the inconvenience that this is causing.

Regards,

Victor

[jtmiii]

This reply apparently never posted yesterday - the website recovered it today - reposted for completeness..

James

Downloaded the drivers you linked to. Ran the uninstaller first, then ran the installer - which should ensure that only the latest drivers are loaded. Then rebooted windows which should have pushed any in-memory drivers out of the way and then ran MCUxpresso again. Chose the unmodified Hello World demo from the SDK and used the "Debug As..."/MCUxpresso... 

Unfortunately - same message, same error.

[jc_pacheco]

James,

Just as a quick test... Can you try booting from the fuses mode and then try to flash the device using MCUXpresso in Windows?
This is done by configuring the SW7 switch to 0000:

Please confirm this is how your board is enumerated during probe discovery:

If it works, then switch back to Internal boot mode(SW7 configuration 0010):

Please let me know if this worked for you. Either way, I'm tracking internally this issue to report it to our tools team.

Regards,

JC

[jc_pacheco]

Hi James,

Could you please provide an image of your setup? The LPC-Link2 port is J4, the other ports can't be used to flash the board.

Just to make sure, do you have the latest LPC-Link2 Windows driver?

[ChrisN]

Duplicate of https://community.nxp.com/thread/456134 

There is an issue with the USB link to the CMSIS-DAP "LPC-Link2" type debug adapters under Windows for some people.

Since NXP won't acknowledge that there is a problem, you have the option to either reinstall Windows or use another PC or OS. Or, use a JLink debug adapter.

[jtmiii]

Based on a few scans of the community pages - several items popped up as far back as March 2019 which seem to describe the same error - yet none of these seem to be answered with a definitive "This is what is wrong..." -- the answers all seem to want to blame the user not the software. No my board is not bricked - IF I use OSX based MCUxpresso - I can load any application I wish - reload it, load a different application and it all seems to work. 

IF I use Windows 10 based MCUxpresso - the error occurs on EVERY attempt to load an application. 

Given that I have been using MCUxpresso, LPCxpresso and CodeRed for over 10 year, with multiple boards, MCUs and programming pods, I'm pretty sure that it's not just operator error.

So the question still stands - what is wrong with the Windows 10 MCUxpresso installation that only it does not work?

The related links are:

March 15 2019: Failed on connect: Ee(42). Could not connect to core. No connection to chip's debug port 

July 1, 2019: Rookie meets Error in final launch sequence when practicing the 'hello world' demo 

August 25, 2019: Failed on connect: Ee(42). Could not connect to core. 

The last one even starts as "This question have been asked several times! But I have found no good answers."

The fact pattern is clear - there is a serious disinterest in getting this problem resolved. 

This causes me to ask the more important question - if the tool chains are so fragile, how can I rely on them to build my product? Certainly this would never pass muster for a project that had to meet DO-187 or DO-278 reliability assurance standards where not only the application software but the tool chains are independently verified. I'm amazed that the tools can meet the automotive reliability standards.

As for the quality of the replies - it appears someone failed their software ethics classes - "Admit your bugs, Own your bugs, Fix your bugs."

Given that the reason for buying the RT1060 EVK was to learn more about NXP's ML and TF offerings, during the virtual Webinar on Aug 26/27 2019, this issue totally derailed that effort. But I guess that's ok - since it has been replaced with the discussion of whether we continue to consider the RT106x processor in our application.

[victorjimenez]

Hello James,

Based on the information that you mentioned it seem that you bricked your board. In a couple of minutes, I will send you to your email a step-by-step guide that explains how to recover it. 

For further communication please reply directly on this communtiy thread.

Have a great day,
TIC

-------------------------------------------------------------------------------
Note:
- If this post answers your question, please click the "Mark Correct" button. Thank you!

- We are following threads for 7 weeks after the last post, later replies are ignored
Please open a new thread and refer to the closed one, if you have a related question at a later point in time.
-------------------------------------------------------------------------------

[vageeshpanditha]

Hi Victor,

Please share the steps to recover the board as Mass erase also not happening even in SW 7 - 0000.

VAGEESH.PANDITHARADHYA@arrowasia.com

Regards,

Vageesh K M

[jtmiii]

No the board is definitely functional - if I work from OSX - was able to download blinky, hello world and the edwin slideshow and they all work as expected.

The problem is that I can not program the board from windows. I also have a RT1064 EVK board that exhibits identical problems with the Windows version.

I will try the linux version of MCUxpresso later tonight and confirm it works.

Thanks

James