dfutil does not work: Linux, LPC Link2

[lpcware]

Content originally posted in LPCWare by arataj on Wed May 07 10:22:24 MST 2014
Hello.

Linux Mint 16 64 bit, the 32 bit libraries installed as required. I attach a LPC Link2 board, with LPC11U35 board connected via JTAG. The red diode switches on on the Link2 board.

$ dfu-util -l
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

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


$ dfu-util -d 1FC9:000C -c 0 -t 2048 -R -D ./lpcxpresso/bin/LPC432x_Redlink_V4_26.bin.hdrdfu-util -d 1FC9:000C -c 1 -t 2048 -R -D ./lpcxpresso/bin/LPC432x_Redlink_V4_26.bin.hdr
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0

Filter on vendor = 0x1fc9 product = 0x000c
Opening DFU 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=471
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


(The red diode switches off)

dfu-util again, now find nothing:

$ dfu-util -l
dfu-util 0.5

(C) 2005-2008 by Weston Schmidt, Harald Welte and OpenMoko Inc.
(C) 2010-2011 Tormod Volden (DfuSe support)
This program is Free Software and has ABSOLUTELY NO WARRANTY

dfu-util does currently only support DFU version 1.0


Re-attaching the board to a different USB port - the same repeats. LPCXpresso shows "connection refused". Both 32bit libudev0 and libudev1 are present.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu May 08 13:30:26 MST 2014
As a TEMPORARY, workaround, when you receive this error, just kill the process 'redlinkserv'. Do not do anything else. Do not run dfu-util, do not unplug lpc-link2.

I will respond with a fuller explanation and hopefully a proper resolution shortly.

[lpcware]

Content originally posted in LPCWare by arataj on Thu May 08 12:17:35 MST 2014
Of course, the state of the diode might be irrelevant. I just report, what  I saw. The red diode switching off in the meantime, and switching on again after re-plugging might be just a coincidence. The Link2 board is connected via JTAG to LPC11U35 board, by the way. I attach the project debugged.

The debug session, if starts at all, works correctly. Then I terminate it, and start a new session. It either works again, or shows "connection refused". If the latter happens, no more sessions start, even if the IDE is restarted, unless LPCLink 2 is replugged.

The tries so far were on a desktop machine. But, to exclude hardware problems, I have also tried to debug on a laptop as well, especially that the laptop has Windows 7 installed. Firstly, I installed the IDE on Mint 16, and the problems were the same as on the desktop. Then, I installed the IDE on Windows 7. This time, the debugging worked perfectly - I rebuilt the project, ran debugging a number of times, rebuilt again, debugged etc., all without problems.

So, on the two machines, problems are on all Linux distros I tested, either 64bit or 32bit. But on Windows 7 on the same hardware, no problems happen.

Perhaps it will be some hint: dfu-util -l initially lists the board:

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

After a failed debugging session (I am not sure what happens after a successfull session now), dfu-util does not list the board any more. Re-plugging makes the utility list the board again.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu May 08 10:52:00 MST 2014
Sorry, this makes no sense. The state of the led is largely irrelevant, so that does not help.

If it debugs sometimes, then you have a working setup, so you can ignore that.

When debug fails, what error messages are you getting?

Btw. Are you terminating the debug session before staring another?

[lpcware]

Content originally posted in LPCWare by arataj on Thu May 08 10:21:38 MST 2014
I have tried Mint 16 64 bit, 32 bit, and Ubuntu 14 32 bit, with both a link to udev1 or a separate udev0. It turns out connecting problems are similar on all these systems:

1. If the red diode is off, redlinkserv must be killed, and LPC Link2 replugged to make the red diode on again.
3. Then, debugging works sometimes never, sometimes once, sometimes several times. It all ends
with the diode switching off.
4. Then, no replugging helps. It makes the diode switch on, but after an attempt to debug, the diode just instantly switches off and "connection refused".
5. Going to 1 repeats the sequence.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu May 08 00:25:00 MST 2014
So, I just installed Linux Mint, and I then installed the 32 bit libraries as described in the User Manual.

I installed LPCXpresso 7.1.1, and finally, I followed the advice in the FAQ:

cd /lib/i386-linux-gnu
sudo ln -sf libudev.so.1 libudev.so.0

and redlinkserv will now run.

*Edit*
I notice that you were not running the supplied version of dfu-util. Further investigation shows that under Mint (and Debian, I think), you also need to install

sudo apt-get install libusb-0.1-4:i386

To get the supplied version of dfu-util to run. However, as you found, the 'standard' version does also seem to work.

[lpcware]

Content originally posted in LPCWare by arataj on Wed May 07 11:14:38 MST 2014
Yes, I have read the FAQ, and tried linking udev0 to udev1 as suggested. Then I also tried to install a separate udev0:

i386-linux-gnu # ls *udev* -l
libudev.so.0 -> libudev.so.0.13.0
libudev.so.0.13.0
libudev.so.1 -> libudev.so.1.3.5
libudev.so.1.3.5

It did not change anything, though. What d-script to run with dtrace?

$ dtrace /home/local/lpcxpresso_7.1/lpcxpresso/bin/redlinkserv
Usage /usr/bin/dtrace [--help] [-h | -G] [-C [-I<Path>]] -s File.d [-o <File>]

Running redlinkserv directly does not bring any missing library messages. I can switch from Mint 16 64-bit to 32-bit. Would it make sense to switch directly to Ubuntu, if Mint is its derivative? I might try it as well.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed May 07 10:41:08 MST 2014
Have you read the FAQ?
http://www.lpcware.com/content/faq/lpcxpresso/connection-refused-linux

If you have, then run

dtrace redlinkserv

And look through the output for a missing library. If you can't find it, post the entire output and we may be able to help. No promises, as mint is not an officially supported distro.