topic Re: MCUExpresso with LPC-Link2 in MCUXpresso IDE

MCUExpresso with LPC-Link2

JohnDeMar — Fri, 21 Apr 2017 15:30:50 GMT

I'm running MCUExpresso with our custom LPC4330 hardware and a Keil ULink2 JTAG interface. It has been working fairly well, but we'd like to use the lower-cost LPC-Link2 for other people in our group.

I have an LPC-Link2 brand new, out of the box. I've followed a variety of misc online instructions, and I believe I have it set up correctly. But, it does not work.

Is there a definitely source for information on getting the LPC-Link2 running with MCUExpresso?

-John DeMar

https://www.linkedin.com/in/jsdemar/

Re: MCUExpresso with LPC-Link2

lpcxpresso_supp — Fri, 21 Apr 2017 16:32:18 GMT

John,

A DOA LPC-Link2 is a very rare occurrence. What is your host system? If Windows, first make sure the appropriate drivers are installed.

Booting LPC-Link2

There are two jumpers on the LPC-Link2 board, JP1 and JP2. A connected JP1 boots the probe firmware from flash. To flash the probe firmware, you'll first need LPCScrypt. Instead, if you leave JP1 open, the processor boots to DFU mode. The MCUXpresso IDE will recognize an LPC device, and DFU the probe firmware.

Once the DFU is complete, you should see a CMSIS-DAP probe boot up as a Windows connected device.

Thanks and regards,

LPCXpresso Support

Re: MCUExpresso with LPC-Link2

JohnDeMar — Fri, 21 Apr 2017 21:00:26 GMT

Here's what I get when I boot with jumper 1 removed (DFU mode):

I ran MCUXpresso and went to the "chip" icon to erase flash:

It sees the device and could erase the external SPIFI flash in our target. Good so far.

But, when I try to run a debugger session, I get this:

I tried with and without JP2 installed (buffer power). Same error.

My debug config for the project looks like this:

So, I used LPCScrypt and flashed it with CMSIS-DAP. Installed jumper 1 and power cycled the LPC-Link2.

It showed up like this in Devices and Printers:

A slightly older version that the one MCUXpresso loads (5.182).

I repeated the session with the same error when trying to start the debugger.

I repeated with LinkServer changed to "LPC-Link (HID)" and "LPC-Link (WinUSB) or RDB-Link" under Properties -> Run/Debug Settings -> (Project debug name) -> Edit Launch Config Properties -> Debugger -> Emulation selection. Same problem.

After all these failed sessions, I have to install the ISP jumper on our target to erase or flash the SPIFI.

I went back to the ULink2 and repeated the above with the LPC-Link2 unplugged. The debugging session worked fine under MCUXpresso.

What else can I try??? Our target board is LPC4330 set for SPIFI boot.

-John DeMar

https://www.linkedin.com/in/jsdemar/

Re: MCUExpresso with LPC-Link2

lpcxpresso_supp — Mon, 24 Apr 2017 14:50:39 GMT

John,

Based on the information above, the IDE has good communications with the debug probe (despite the slightly miss-leading error), the problem is that the LPC-Link2 cannot communicate with the target MCU. (You would see exactly this behaviour if there was no 10 way debug connection to the board).

Therefore initially I would focus on the physical connection from the LPC-Link2 to your target.

1 - check the basics, is the 10 wire debug cable connected to J7 on the LPC-Link2 board

2 - is the wire orientation correct onto your custom LPC4330 hardware

3 - check the target is powered either locally or via the LPC-Link2 (JP2 link made)

I appreciate that you have a good debug connection via Keil ULink2 JTAG interface, but the following document may be worth reading:

Design Considerations for Debug

Yours,

LPCXpresso Support

Re: MCUExpresso with LPC-Link2

JohnDeMar — Mon, 24 Apr 2017 15:17:59 GMT

The LPC-Link2 can erase and flash our target, so there is not the same as having the 10-pin header disconnected.

There appears to be different timing in the LPC-Link2 code when flashing vs debugging. We are looking at the reset circuit implementation on our target. It has an active reset supervisor with an internal pullup, but it also monitors the reset signal and assert a stretch to nominally 150msecs.

Is there open source to the LPC-Link2 code so that I can allow it to wait longer when asserting a reset before looking for the CPU?

-John

Re: MCUExpresso with LPC-Link2

lpcxpresso_supp — Mon, 24 Apr 2017 16:34:34 GMT

Hi John,

The LPC-Link2 firmware has a couple of proprietary additions, so it's not open source. And, you don't need it. I'd recommend you add a custom reset script with a built in delay. LinkServer includes an example script which can be used to program a delay. See the delayexample.scp in the Scripts folder.

When a reset script is used, MCUXpresso presumes everything reset related is included in the script. So, for example, you'll need to add a command to send a core reset signal to the part. I've cut and paste a script below should do what you need. Note you'll edit your project debug configuration to use a reset script.

Thanks and regards,

LPCXpresso Support

Example script:

100 REM -----------------------------------------------------------------
110 REM LPC4330 Reset Script (500 ms delay loop)
120 REM -----------------------------------------------------------------
130 REM Find probe index and select probe+core
140 REM -----------------------------------------------------------------
150 p% = ProbeFirstFound
160 SelectProbeCore p% 0
170 REM -----------------------------------------------------------------
180 REM Ensure reset vector catch is set
190 REM -----------------------------------------------------------------
200 CMResetVectorCatchSet this
210 REM -----------------------------------------------------------------
220 REM Issue VECTRESET
230 REM -----------------------------------------------------------------
240 CMVectResetReq this
250 REM -----------------------------------------------------------------
260 REM Set initial timer value (milliseconds * 10)
270 REM -----------------------------------------------------------------
280 t% = TIME
290 PRINT "Time:    "; t%
300 REM -----------------------------------------------------------------
310 REM Current timer value is v%
320 REM -----------------------------------------------------------------
330 REPEAT
340   v% = TIME
350   e% = v% - t%
360 UNTIL e% >= 5000
370 REM -----------------------------------------------------------------
380 REM Elapsed time in milliseconds
390 REM -----------------------------------------------------------------
400 e% = e% / 10
410 PRINT "Elapsed (ms): "; e%
420 REM CMResetVectorCatchClear this
430 END

Re: MCUExpresso with LPC-Link2

JohnDeMar — Mon, 24 Apr 2017 18:19:13 GMT

Following this thread: LPCXpresso, LPC-Link2 and RESET line

I turned off "Pull ISP on reset", under Windows->Preferences_>LinkServer Options:

Even though I do not have the ISP line attached on our target, the LPC-Link2 still uses the RESET line if that mode is enabled.

And I set "Attach Only" to "False" under the Project's debugger configuration, which allows scripts to run:

I no longer see the RESET signal being asserted low upon initiating a debugger session. That was causing the Reset Supervisor IC to stretch the reset longer than the debugger's wait time.

Note that it doesn't need the reset delay script you suggested. It wouldn't help anyhow because the debug mode looks for the CPU cores before it runs the script.

-John

Re: MCUExpresso with LPC-Link2

lpcxpresso_supp — Mon, 24 Apr 2017 20:42:29 GMT

Glad to hear you've connected. As you discovered in the other forum thread, the timed delay concept can also be leveraged from a connect script when needed.

Thanks and regards,

LPCXpresso Support

Re: MCUExpresso with LPC-Link2

JohnDeMar — Mon, 24 Apr 2017 21:26:35 GMT

Actually, the connect script is not useful. I didn't have to use it. The required action is to not enable the ISP reset which causes the assertion of the physical reset line. The soft reset from the JTAG commanding is all that's necessary.

If someone wishes to use the ISP pin mode, it is too late in the process when the script is run. The debugger handler already times out looking for the CPU too soon after reset, and never gets a chance to run the delay script. If someone's custom target board uses an active reset supervisor chip, they must not allow the debugger to assert the physical reset (as MCUXpresso is implemented at this time).

-John DeMar

https://www.linkedin.com/in/jsdemar/