Debugger [V5/V6] Does Not Load Redlink Firmware into the LPC-Link2

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Oct 01 03:55:55 MST 2013
Debugger [V5/V6] Does Not Load Redlink Firmware into the LPC-Link2

I am running LPCXpresso 6 on XP pro SP3 -- 32-bit

It is my understanding that after a PC reboot or removal and re-insertion
the Link2 is in "DFU" mode -- and device manager agrees.

I also understand the when I start a debug session, the IDE should
download 'redlink' firmware to the LPC-Link2. Then go on to 'find'
an 'emulator'.

[Firstly: is this overiew stated correctly?]

THIS IS NOT HAPPENING.

The Link2 firmware download is NOT occuring on my PC.
Is there a logging option to see what is happening here to confirm
that this is indeed being attempted and to see what error messages result.

Using Process Explorer (from SystemInternals) and a fast pause finger,
I can see 'Starter' running 'dfu-util -l'.

Running this command by hand gives:

----------------------------
dfu-util 0.6

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
----------------------------

But I never see anything that looks a firmware download.

I had this problem also with Red Suite 5 [256K full licence].
Code Red gave me a work around but DID NOT resolve the issue
before the support period expired!


Using a command line (by hand) given to me by Code Red Support
(adapted for firmware file name change) gives --

----------------------------
dfu-util -d 1FC9:000C -c 0 -t 2048 -R -D LPC4320_Redlink_V2_2.bin.hdr
dfu-util 0.6

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY

Filter on vendor = 0x1fc9 product = 0x000c
Opening DFU capable USB device... ID 1fc9:000c
Run-time device DFU version 0100
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [1fc9:000c] devnum=0, cfg=1, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting #0 ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
DFU mode device DFU version 0100
No valid DFU suffix signature
Warning: File has no DFU suffix
bytes_per_hash=459
Copying data from PC to DFU device
Starting download: [##################################################] finished
!
unable to read DFU status
can't detach
Resetting USB to switch back to runtime mode
----------------------------

From then on until reboot or LPC-Link2 removal reinsertion, the IDE
debug succeeds.

How can the automatic firmware download be made to happen.

Regards, Mike

PS Do any other users have this problem?

[lpcware]

Content originally posted in LPCWare by eamonnh on Thu Nov 07 11:51:29 MST 2013
I upgraded the Renasas FW and driver to 2.1.39. Success! The Link2 works perfectly on the USB3.0 port now.
Thank you very much for your persistance in following this up.
Much appreciated!
Eamonn

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Nov 07 06:35:55 MST 2013
Having investigated a bit further, the most likely cause is that you need a firmware update for your USB3 controller.

if you are using a NEC/Renesas USB 3.0 controller, such as the fairly widespread uPD720200/uPD720200A, please make sure that your controller drivers are ​version 2.1.16.0 or later.

http://www.station-drivers.com/index.php/10-drivers/42-renesas-nec

Hope that helps

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 06 03:42:00 MST 2013
Thanks for updating us and I am glad you are now up and running.

Yes, there are still issues with some USB 3.0 controllers. We have not come across the Renasas controller before, so we will investigate.

Best Regards

[lpcware]

Content originally posted in LPCWare by eamonnh on Wed Nov 06 03:31:36 MST 2013
Hi NXP Support,
Thanks for jumping in!
I had been trying dfu-util -l with no success. Device Manager and USBView were both showing the LPC device.
Then I followed your first suggestion: switch USB ports; and immediately dfu-util shows a DFU device.
My Link2 is working perfectly now!

Debug works with a single click - no need to download debugger FW or even start Redlink. All works automatically.

It just didn't occur to me to switch ports because this particular one is the one I always use for all my debuggers. Yet it just does not work with the Link2 for some reason. For the record, the USB port that does not work is a Renasas USB 3.0 Host Controller, while the two that work are both Intel 6 Series/C200 Series USB Enhanced Host Controller. (It may be related to USB 3.0, who knows?)

I very much appreciate your helpful suggestions, and I'm delighted to see my 2 LPC-LINK2 debuggers working at last.
Thank you very much.

Eamonn

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Nov 06 02:18:17 MST 2013
Can you try typing

dfu-util -l

This will list the DFU capable devices that can be seen by the dfu utility.

If no devices are reported, then there is a problem with your system. Suggested things to try:
- switch USB ports (not all USB ports are created equal)
- try different USB cables
- try completely uninstalling the driver and re-installing
- Does Device Manager report a device called "LPC"

Note: The reference to requiring 32-bit drivers is Linux specific. We supply and automatically install drivers for both 32-bit and 64-bit Windows.

[lpcware]

Content originally posted in LPCWare by eamonnh on Tue Nov 05 11:25:25 MST 2013
Hi Mike,
Thanks for your suggestion. Just tried the 6.0.4 version and same result: No DFU capable device found. I'm trying to talk to an LPC4330 via LPC-LINK2 on Xpresso. Works fine with RedProbe+. Never managed to get any response out of the Link2's. That's why I checked the USB interface with Microsofts USBView, to see if it's actually booting as a DFU device.

I'm running Win7Pro 64-bit. Perhaps this is a problem?

In FlySnake's thread, ( http://www.lpcware.com/content/forum/lpc-link2-connection-refused-linux ), I recall NXP Support suggesting that 32-bit libraries were needed to make things work on a 64-bit OS, but I'm not clear if that applies to Linux or Windows or both.

I've tried running redlinkserv and that all seems to work fine. I can telnet to it but PROBELIST returns zero connected probes.

When I saw your thread, I thought I'd try directly DFUing the firmware. And failed. But it's good to hear at least somebody is making progress with Link2's.
Thanks again - Eamonn

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Tue Nov 05 09:41:44 MST 2013
My example was with version 6.0.4.

Try installing that and retry the experiment.

Also check the EXACT filename of the redlink firmware file, it may have changed in 6.1
Note (from your posting) is appears that the Dfu-util is up a version -- something may have broken.

As the Dfu-util does not find the device, it may be a driver issue -- I am on XP.

Also after firmware HAS been downloaded, the VID/PID change and dfu-util
won't find the 'dfu capable' device anymore.

HTH -- Mike

[lpcware]

Content originally posted in LPCWare by eamonnh on Tue Nov 05 07:34:20 MST 2013
Hi Mike,
I tried your solution to command-download the FW with the following result:

C:\nxp\LPCXpresso_6.1.0_164\lpcxpresso\bin>C:\nxp\LPCXpresso_6.1.0_164\lpcxpresso\bin\dfu-util.exe -d 1FC9:000C -c 0 -R -D C:\nxp\LPCXpresso_6.1.0_164\lpcxpresso\bin\LPC432x_Redlink_V3_27.bin.hdr
dfu-util 0.7

Copyright 2005-2008 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2012 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to [email protected]

Filter on vendor = 0x1fc9 product = 0x000c
No DFU capable USB device found

I checked out 2 LPC-LINK2 boards I have here with USBVIEW with this result:
-----------------------------------------------------------
Device Descriptor:
bcdUSB:             0x0200
bDeviceClass:         0x00
bDeviceSubClass:      0x00
bDeviceProtocol:      0x00
bMaxPacketSize0:      0x40 (64)
idVendor:           0x1FC9
idProduct:          0x000C
bcdDevice:          0x0100
iManufacturer:        0x01
0x0409: "NXP"
iProduct:             0x02
0x0409: "LPC"
iSerialNumber:        0x03
0x0409: "ABCD"
bNumConfigurations:   0x01

ConnectionStatus: DeviceConnected
Current Config Value: 0x01
Device Bus Speed:     High
Device Address:       0x01
Open Pipes:              0

Configuration Descriptor:
wTotalLength:       0x001B
bNumInterfaces:       0x01
bConfigurationValue:  0x01
iConfiguration:       0x00
bmAttributes:         0xC0 (Bus Powered Self Powered )
MaxPower:             0x32 (100 Ma)

Interface Descriptor:
bInterfaceNumber:     0x00
bAlternateSetting:    0x00
bNumEndpoints:        0x00
bInterfaceClass:      0xFE
bInterfaceSubClass:   0x01
bInterfaceProtocol:   0x01
iInterface:           0x04
0x0409: "DFU"

HID Descriptor:
bcdHID:             0x0009
bCountryCode:         0xFF
bNumDescriptors:      0x00
----------------------------------------------------------
In my case, it looks as if the devices may not be properly configured as DFU devices from the boot-rom.
JP1 and JP2 off for these tests.

Thanks - Eamonn

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Oct 02 06:48:02 MST 2013
Mike,

You are not the only XP user, but you are the only one that is reporting any problems.

You can get additional information by starting lpcxpresso with the -debug flag. This will show a LOT of additional information in a new (DOS) Window. Press the Red Boot icon on the toolbar, and this will just try to boot adapters that it can find. The output will show the commands run and the responses received.

[lpcware]

Content originally posted in LPCWare by mshahabi on Wed Oct 02 06:40:53 MST 2013
Thanks for the help,

      You were correct on both suggestions; "Use Redlink Server" & "Using Quicklanch debug button". It is working now.

Best regards,
M.Shahabi

[lpcware]

Content originally posted in LPCWare by mshahabi on Wed Oct 02 06:33:05 MST 2013
Thanks for your help,

     In fact I had looked at the FAQ. I have been using the lpc-link2 without the JP2 all along. On the silk screening of the lpc-link2 it describes JP2 as "buffers pwr by link2" or " ...by target". This tells me that this jumper only selects source of power. I was wondering if this is a typo and the author means JP1, as JP1 is the one which is described in the "configuration tool" for programming images ( ie, when "JP1 open: Boots from USB DFU" ).

      BTW, I have used the module with and without the JP1 with the target with no redlink luck.

Regards,

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed Oct 02 06:13:33 MST 2013
LPC-Link2 is actually called "Redlink Server" in the Emulator selection. LPC-Link is the original emulator on LPCXpresso boards.

Actually, the simplest thing to do is let the IDE do all the work for you. Delete you launch configurations and press the Quicklanch debug button. The IDE will automatically find and use LPC-Link2 for you.

[lpcware]

Content originally posted in LPCWare by whitecoe on Wed Oct 02 06:10:14 MST 2013

---

Quote: mshahabi

    I am wondering if I have to take another step after having used the "configuration tool" to experiment/program LPC-Link2 with J-Link or CMSIS-DAP firmware?

---

LPCXpresso6 will work with CMSIS-DAP firmware programmed into a Link2. But if you want the Link2 to boot as a redlink probe, then you need to make sure JP2 is not fitted. This FAQ gives some details...

http://www.lpcware.com/content/faq/lpcxpresso/lpc-link2-support

HTH!

[lpcware]

Content originally posted in LPCWare by mshahabi on Wed Oct 02 05:51:48 MST 2013
Hello,

     I am encountering similar problem with Windows 7 Professional SP1, LPCXpresso v6.0.2 [Build 151] and LPC-link2. I was able to successfully program the lpc-link2 with either of the J-Link debugger image and CMSIS-DAP image using the configuration tool and connect to Keil's MCB4300  & uVision though.

     In case of the redlink apparently you don't need to load the firmware and LPCXpresso loads it upon your first debug attempt. I create a new "Hello World" project and build it successfully. When I want to debug the image a "c/c++ application" debug configuration is made instead of a "c/c++ MCU application". If I manually create "MCU application" and then under Debugger tab select LPC-LINK as "Emulator selection", then press "Edit JTAG configuration" I see the error message in the pop-up complaining about LPC-Link not being found.

    I am wondering if I have to take another step after having used the "configuration tool" to experiment/program LPC-Link2 with J-Link or CMSIS-DAP firmware?

Regards,
M.Shahabi

[lpcware]

Content originally posted in LPCWare by MikeSimmonds on Wed Oct 02 03:44:31 MST 2013
Thank you for your reply, but ...

What do you mean by "Frankenstein" nature? This implies some sort of hand built setup.
I have a standard XP 32bit OS (Legal Dell Boot disk) on a standard AMD quad core mother board.
Details Appended. Are you confusing me with another user?

I can't be your only user with XP.

However, you have not given me any hints as to how to track down the problem.
Can you not point me to logfiles or similar? Expected driver registry entries? I don't know what else.

Regards, Mike

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Oct 02 03:09:31 MST 2013
Yes, we would expect LPC-Link / LPC-Link2 to be automatically booted when you start a debug session.

We are not aware of other users having similar problems to those you report. Based on previous issues that you have reported, I imagine that your issues are again down to the rather special "frankenstein" nature of your PC and its OS installation.

If you continue to see problems with automatic probe booting, then you should be able to just continue to manually boot your probe in LPCXpresso 6 either from the command line, or by using the "Boot Debug Probe" icon on the toolbar (a red boot).

Also be aware that the Redlink firmware provided with LPCXpresso/Red Suite 5 is very different to that provided in LPCXpresso 6. You should ensure that you use the firmware provided with each tools version. Thus if you boot the probe with one tool version, then switch to the other, you will need to pull the plug on the probe and reboot it before debugging again.

Regards,
LPCXpresso Support