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

Discussion created by lpcware

on Jun 15, 2016
Latest reply on Jun 18, 2016 by lpcware

Like • Show 0 Likes0
Comment • 8

Content originally posted in LPCWare by kurtm on Mon Mar 14 09:26:10 MST 2016
I have problems to program my LPC824 parts.

I have two programmers, one LPC-Link 2 and one LPC82x Xpresso V2 mbed.
I have recently updated to latest version of LPCXpresso (8.1.2)

When trying to program flash, I will get error message: Failed on connect: Ee(36). Could not connect to core.

I have modified the LPC82x Xpresso V2 mbed card so that I can connect an external card, but with jumpers so that I still can program the CPU on the board. This has worked OK earlier with several boards and an earlier version of LPCXpresso (7.something). I can still program the CPU on the board, but not external cards. I have tried to program 3 external cards with both my programmers, but I always get the same error message.

I see some brief activity on SWDIO and SWCLK on the chip when programming. I have tried with 47K pullup on SWDIO and 47K pulldown on SWCLK (as fig 11 page 30 in datasheet) and also without resistors on these pins, but there is no difference.

Could someone clarify wat the error code Ee(36) means? It might be helpful to resolve the problem. I think it would be nice with an explanation of all error codes.

Kurt Mirdell

When testing some more, I managed to connect one single time. Flashing was made without any problem. Image loaded was periph blinky. It works and toggles one pin. However, after that it was impossible to do connect again. Same error message. I suspect that there is some connecton problem and shorted the connection length from 30 cm to 8 cm, but still no connect.

Outcomes

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 14 11:49:18 MST 2016

The debugger is being told by the server program it can't establish a debug connection to your processor.

Please read the following FAQ:

Regaining debug access to target MCU

If you do not recover debug access after following the above steps, it would help if you increased the log setting and captured the connect sequence.

To increase the log setting, first access your debug configuration. From the menu bar Run -> Debug Configurations -> C/C++ (NXP Semiconductors) MCU Application -> <project name> Debug -> Debugger <tab> -> Target Configuration -> Debug Level. Default is 2, set it to 4.

Next, in the Preferences, set the DEBUG_TRACE setting to 0x30000. This is Preferences -> LPCXpresso -> Debug Options (Advanced) -> Extended debug trace (DEBUG_TRACE).

Attempt to connect the debugger once again, and copy the gdb-traces and project debug console output to separate files and attach to your response.

Thanks and regards,
LPCXpresso Support

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by mch0 on Mon Mar 14 11:54:14 MST 2016
Hi,

I had a similar problem with 8.1.2 and a CMSIS-DAP probe. I am working with an LPC43xx as target, but maybe my "solution" is of some help to you, too.

a) If you currently use "JTAG" as debug interface protocol I recommend switching to SWD. This saved me in one case. It uses 2 wires less, reducing the chance of HW problems.

b) You may try to kill and restart the Redlink Server. You can do that from within the IDE. Select the "Redlink Server"-Console by the"red chain" button in the top bar.
When this console is displayed it is the red square button of the console window. You can then reboot the server again, also from within the IDE (top bar, red boot).
Sometimes this has also saved me by probably clearing some residual state of the server/probe/IDE whatever.

Good luck,

Mike

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 14 12:01:20 MST 2016

Please note the CMSIS-DAP firmware resident on the MBED board does not support the JTAG protocol. Even if it did, the LPC824 processor does not.

Thanks and regards,
LPCXpresso Support

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by kurtm on Thu Mar 17 11:56:34 MST 2016
Thanks for all answers.

I tried to follow the instructions, but couldn't find the gdb-traces. I still think it would be nice to get some explanation of error codes.

However, I have now managed to program all parts. I have never tried to use JTAG interface, only SWD interface.

My problem is that I have a limited number of pins (3) in a connector where I am trying to combine programming functions with functions during normal operation.

On one board, the problem was that the software loaded in the processor was driving SWDIO through another pin. This one worked when I did the ISP reset first.

On another board, I had connected SWDIO with TRST. The processor was empty. This worked when I disconnected TRST from the SWDIO pin. The plan here was to use the TRST pin as a GPIO. I got the impression from the data sheet that TRST only had a function in boundary scan mode, but that doesn't seems to be true.

Which 3 signals would be most useful for programming? SWDIO and SWCLK are two obvious signals, but which one is best as third? Is maybe ISP entry pin (PIO0_12) better than RESET pin? I want to be able to program both empty parts and programmed parts.

Of these 3 pins, I would like to use 2 as outputs during normal operation. Either I can connect a general I/O pins to two of the programming pins or reprogram the programming pins with the switch matrix. Which solution is best and which programming pins should I use as outputs?

Would it be neccessary to delay programming pins as outputs to avoid conflicts with programming? This could be done with a time delay or by using the input pin.

Best regards

Kurt

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 17 15:38:06 MST 2016
gdb-traces is another console accessible through the console tab. I know of no vendors who use TRST, and I'm confused why you would think to tie it SWDIO unless by accident. Regarding using two of these pins as GPIO for your application, it makes little difference which ones you appropriate. The end result is there's no way to debug your deployed code during normal operation.

I would recommend you insert a timing delay in your code before you redirect any debug pin as GPIO. This allows a window of time for the debugger to connect after a reset.

Thanks and regards,
LPCXpresso Support

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by kurtm on Fri Mar 18 03:43:54 MST 2016
The reason I tied TRST to SWDIO was to use the TRST pin as GPIO output. I did not have any intention to use the TRST function.

Is RESET of any use when I program the part?

If I only have 3 connections, would it be better to have ISP entry pin instead of RESET as third pin?

Best regards

KurtM

Actions

lpcware

Jun 15, 2016 1:12 PM

Content originally posted in LPCWare by lpcxpresso-support on Fri Mar 18 09:02:21 MST 2016

The 3 pins you should bring out to the debug connector are SWCLK, SWDIO, and RESET. A standard debug connector has no definition for an ISP line. Having said that, being able to boot the part into the ISP is useful in your situation, but this requires both ISP and RESET.

Thanks and regards,
LPCXpresso Support.

bump

8 Replies

lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 14 11:49:18 MST 2016

The debugger is being told by the server program it can't establish a debug connection to your processor.

Please read the following FAQ:

Regaining debug access to target MCU

If you do not recover debug access after following the above steps, it would help if you increased the log setting and captured the connect sequence.

To increase the log setting, first access your debug configuration. From the menu bar Run -> Debug Configurations -> C/C++ (NXP Semiconductors) MCU Application -> <project name> Debug -> Debugger <tab> -> Target Configuration -> Debug Level. Default is 2, set it to 4.

Next, in the Preferences, set the DEBUG_TRACE setting to 0x30000. This is Preferences -> LPCXpresso -> Debug Options (Advanced) -> Extended debug trace (DEBUG_TRACE).

Attempt to connect the debugger once again, and copy the gdb-traces and project debug console output to separate files and attach to your response.

Thanks and regards,
LPCXpresso Support
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by mch0 on Mon Mar 14 11:54:14 MST 2016
Hi,

I had a similar problem with 8.1.2 and a CMSIS-DAP probe. I am working with an LPC43xx as target, but maybe my "solution" is of some help to you, too.

a) If you currently use "JTAG" as debug interface protocol I recommend switching to SWD. This saved me in one case. It uses 2 wires less, reducing the chance of HW problems.

b) You may try to kill and restart the Redlink Server. You can do that from within the IDE. Select the "Redlink Server"-Console by the"red chain" button in the top bar.
When this console is displayed it is the red square button of the console window. You can then reboot the server again, also from within the IDE (top bar, red boot).
Sometimes this has also saved me by probably clearing some residual state of the server/probe/IDE whatever.

Good luck,

Mike
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by lpcxpresso-support on Mon Mar 14 12:01:20 MST 2016

Please note the CMSIS-DAP firmware resident on the MBED board does not support the JTAG protocol. Even if it did, the LPC824 processor does not.

Thanks and regards,
LPCXpresso Support
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by kurtm on Thu Mar 17 11:56:34 MST 2016
Thanks for all answers.

I tried to follow the instructions, but couldn't find the gdb-traces. I still think it would be nice to get some explanation of error codes.

However, I have now managed to program all parts. I have never tried to use JTAG interface, only SWD interface.

My problem is that I have a limited number of pins (3) in a connector where I am trying to combine programming functions with functions during normal operation.

On one board, the problem was that the software loaded in the processor was driving SWDIO through another pin. This one worked when I did the ISP reset first.

On another board, I had connected SWDIO with TRST. The processor was empty. This worked when I disconnected TRST from the SWDIO pin. The plan here was to use the TRST pin as a GPIO. I got the impression from the data sheet that TRST only had a function in boundary scan mode, but that doesn't seems to be true.

Which 3 signals would be most useful for programming? SWDIO and SWCLK are two obvious signals, but which one is best as third? Is maybe ISP entry pin (PIO0_12) better than RESET pin? I want to be able to program both empty parts and programmed parts.

Of these 3 pins, I would like to use 2 as outputs during normal operation. Either I can connect a general I/O pins to two of the programming pins or reprogram the programming pins with the switch matrix. Which solution is best and which programming pins should I use as outputs?

Would it be neccessary to delay programming pins as outputs to avoid conflicts with programming? This could be done with a time delay or by using the input pin.

Best regards

Kurt
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by lpcxpresso-support on Thu Mar 17 15:38:06 MST 2016
gdb-traces is another console accessible through the console tab. I know of no vendors who use TRST, and I'm confused why you would think to tie it SWDIO unless by accident. Regarding using two of these pins as GPIO for your application, it makes little difference which ones you appropriate. The end result is there's no way to debug your deployed code during normal operation.

I would recommend you insert a timing delay in your code before you redirect any debug pin as GPIO. This allows a window of time for the debugger to connect after a reset.

Thanks and regards,
LPCXpresso Support
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by kurtm on Fri Mar 18 03:43:54 MST 2016
The reason I tied TRST to SWDIO was to use the TRST pin as GPIO output. I did not have any intention to use the TRST function.

Is RESET of any use when I program the part?

If I only have 3 connections, would it be better to have ISP entry pin instead of RESET as third pin?

Best regards

KurtM
Like • Show 0 Likes0
Actions
lpcware Jun 15, 2016 1:12 PM
Content originally posted in LPCWare by lpcxpresso-support on Fri Mar 18 09:02:21 MST 2016

The 3 pins you should bring out to the debug connector are SWCLK, SWDIO, and RESET. A standard debug connector has no definition for an ISP line. Having said that, being able to boot the part into the ISP is useful in your situation, but this requires both ISP and RESET.

Thanks and regards,
LPCXpresso Support.
Like • Show 0 Likes0
Actions
lpcware Jun 18, 2016 6:05 PM
bump
Like • Show 0 Likes0
Actions

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

Outcomes

Related Content

Recommended Content