Wire Ack Fault when debugging brand new OM40000 (LPC802 eval kit)

[tomchr]

This morning I received a brand spankin' new eval board from Mouser: NXP P/N: OM40000 (LPC802 development board). The board powered up fine and the code it shipped with ran fine.

However, when I try to program and debug a simple "Hello World" or "Blinky" example onto the board, I get the following error: Exception. Reason: Unable to connect wire for probe index 1. Error: Wire Ack Fault - target connected?

When I click OK, I get another error: 02: Failed on connect. Could not connect to core. 31: No connection to chip's debug port. Debugging context: lpcxpresso802_led_blinky LinkServer Debug.

When I then click OK, more errors: 24^error,msg="Remote connection closed". Reason: Failed to execute MI command. See attached screen shot.

I get the exact same errors when I try to program a standalone LPC802 using an LPC-Link2 (rev. A).

Can anyone shed some light on what's going on here and perhaps help me get unstuck?

Thanks,

Tom

[mj000]

I troubled in same problem, solved by this page, really thanks!!

[tomchr]

Understood. Thanks again for your help.

Tom

[tomchr]

Diego,

Fantastic! That worked.

It brings up another question, though: If I'm using these LPC8xx uCs in production, should I include a pushbutton for ISP in case programming fails? That seems a bit wasteful, both in parts cost and board area.

I would like to use one of the LPC8xx in a low-volume production (QTY 100 at a time). Splurging on a $1k Segger programmer is not currently in the cards. I was hoping to use the LPC-Link2 or one of your eval boards as a programmer. I can certainly switch to the LPC82x or LPC83x for this project. Both of these are supported by LPC-Link2. But will I still need the ISP button with such a setup?

Also: It seems the list of supported devices for the LPC-Link2 is in need of an update. At least it programs both the LPC844 and LPC845 just fine.  

Thanks again for your help so far.

Thanks,

Tom

[diego_charles]

Hi Tom,

I am glad to know that the issue was solved.

Regarding your previous comments:

It brings up another question, though: If I'm using these LPC8xx uCs in production, should I include a pushbutton for ISP in case programming fails? That seems a bit wasteful, both in parts cost and board area.

To enter ISP mode you will need only to pull down the ISP pin during reset (to avoid undesired entraces to ISP,  we recommend to add an external pull up resistor on the pin, adding  robustness ) , therefore you could leave a connection in your design to pull down the pin , for example a pad or a jumper instead a push button.

The main goal of setting the MCU in ISP mode, it is to execute ISP commands by a serial protocol like UART and I2C. In our case doing this, was useful because this halted the normal firmware execution flow and we regained   access the debug port of the MCU.

I hope this helps,

Best regards,

Diego.

edit: adding details on a statement.

[tomchr]

Do you have a sense of how frequently the uC gets stuck in Lala Land? If it's 1% of cases, no big deal. But if it's 99% of cases, I might as well add the mass erase to my programming procedure. I'm having my assembly house do the programming so getting the instructions right is key.

I think I'll just connect the power button of my device to the ISP pin. If the programming doesn't work the first time, hold the power button when the programmer is plugged in. 

Tom

[diego_charles]

Hi Tom,

Thank you for your reply,

Providing a number, it is not an easy task, this because the wide variety of factors to consider!

You should expect a good reliability within our products.

As a general recommendation, you must ensure that the software it is not doing something that may alter the expected behavior of the MCU. This along with a good the hardware design and being sure to meet the working specifications for the MCU , and the other parts that accompany your embedded system,  are key to success.

If you run into unexpected issues, please let us know to help!

BR,

Diego

[diego_charles · Accepted solution]

Hi Tom,

I hope you are doing well!  Here is a first recommendation,

1.  Disconnect the board from any power source.
2. Press and hold ISP pin.
3.  Re-connect the board and release ISP after one second approximately. Now the MCU shall be in ISP mode, this indicates that firmware previously flashed is halted.
4.  While the MCU is in ISP mode, try to perform a mass erase, using any tool you want : using either ISP commands (using flash magic Tool ) or SWD commands (using MCUXpresso  GUI Flash tool or J-link commander)
5.  Try to flash the firmware one more time.

I used to perform these steps when I get this kind of errors, sometimes a wrong clock configuration or any problem in the firmware leads to problems to set the MCU into debug mode.

Another general recommendations that you could follow are: clear. launch configurations (on MCUXpresso IDE) and create a new project workspace and try to flash the Blink example

Please let me know your results.

BR,
Diego.