Debian/Redlink Installation/Execution Problem

[lpcware]

Content originally posted in LPCWare by paul.rcom-software.com on Mon May 19 19:16:24 MST 2014
Dear Staff:

I plan to purchase the commercial version of LPCXpresso and would like
clarification on the root cause of the problems I encountered in making
LPCXpresso work in my OS environment--which is Debian Wheezy 7.5 Linux
with AMD64 architecture. My notes on the installation and execution
procedures are attached to this note. However, I haven't reviewed them
thoroughly and they may contain some inaccuracies or unnecessary steps.
Your comments and criticism of these procedures would be greatly
appreciated.

I think there may be some problem with my and/or the LPCXpresso's use
of the dfu-util program. Briefly, I need to run dfu-util manually, before
starting the LPCXpresso IDE, for it to work correctly. The evidence I
consider relevant follows.

The following command is used to execute dfu-util manually.

dfu-util -d 0x1fc9:0x000c -c 0 -t 2048 -R -D LPC432x_Redlink_V4_26.bin.hdr

It produces the following output.

Opening USB Device 0x1fc9:0x000c...
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0x1fc9:0x000c] devnum=8, cfg=0, intf=0, alt=0, name="DFU"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=471
Starting download: [##################################################] finished!
unable to read DFU status

Notice the last 2 lines of the output. The "... finished!" line implies
the download to LPC-Link2 module succeeded. However, the "unable ... DFU status"
line suggests it failed. Since, after running the command, the LPCXpresso IDE works
correctly, the download must be succeeding. I think the of dfu-util output is
confusing the LPCXpresso software infrastructure--in particular if you actuate
the "Boot Debug Probe" icon.

Best Regards,


Paul Romero

Original Attachment has been moved to: README.install.txt.zip

[lpcware]

Content originally posted in LPCWare by TheFallGuy on Wed May 21 02:30:19 MST 2014

---

Quote:
MODE="666" doesn't work under Debian, because the mode is set to 664 afterwards in /lib/udev/rules.d/91-permissions.rules. Using the group 'plugdev' helps, because the middle 6 still gives read/write access rights to the group.

---

This probably means that just renaming 85-lpcxpresso to 95-lpcxpresso would be work, without the need to adding users to groups etc. (Not forgetting to restart udev after this, of course). [The rules are run in alphabetical order, so '85' gets run before '91', with the '91' rules overriding the ones set by '85']

Perhaps if you could confirm this, we could persuade NXP to rename the file. Well, we can ask anyways...

[lpcware]

Content originally posted in LPCWare by starblue on Wed May 21 02:01:54 MST 2014
To verify that you are in the group 'plugdev' better execute the 'groups' command, because it lists the currently active groups.  Note that after adding yourself to a group (I do it with the 'adduser' command) you will need to login again before it becomes active.

MODE="666" doesn't work under Debian, because the mode is set to 664 afterwards in /lib/udev/rules.d/91-permissions.rules. Using the group 'plugdev' helps, because the middle 6 still gives read/write access rights to the group.

You always need to reload udev rules and maybe replug the device before changes become active. Forgetting this can lead to quite a bit of confusion (I know).

You can trace udev's actions for a USB device by

$ udevadm test /sys/bus/usb/devices/$device

You can figure out $device by looking which one appears when you plug in the device.

(Stupid forum software, no way to get less-than and greater-than characters.)

[lpcware]

Content originally posted in LPCWare by paul.rcom-software.com on Tue May 20 11:52:16 MST 2014
OK - This is the right way to fix the USB permission problem.

* Install a correct udev rules file to the /etc/udev/rules.d directory.
  (i.e. This must be done as super user.)

  Normal user processes, such as LPCXpresso, don't have permission to access
  USB devices due of a problem with the default udev rules shipped with LPCXpresso.
  The name of the file is 85-lpcxpresso.rules and it is in the
  /etc/udev/rules.d directory. (i.e. It is not designed for Debian
  systems.)

  The problem can be corrected by creating or copying a correct rules file
  to the /etc/udev/rules.d directory. You can fix the default rules file
  in the following way:

   Append the GROUP="plugdev" to each line of the file as shown below.

SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0007", MODE="0666", GROUP="plugdev"

   IMPORTANT: Verify that your login ID is in the plugdev group in the /etc/group file,
   and execute the following command after the correct rules file has been installed.

udevadm control --reload-rules

An example of correct udev rules file follows.

**************** Start 85-lpcxpresso.rules *********************************

# Define some simple rules for LPCXpresso supported USB Devices
# Each rules simply makes the device world writable when connected
# thus avoiding the need to run the debug drivers as root

# LPC-Link (unbooted)
SUBSYSTEM=="usb", ATTRS{idVendor}=="0471", ATTRS{idProduct}=="df55", MODE="0666", GROUP="plugdev"
# LPC-Link (winusb)
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0009", MODE="0666", GROUP="plugdev"
# LPC-Link (hid)
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0007", MODE="0666", GROUP="plugdev"
# NXP LPC
SUBSYSTEM=="usb", ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="000c", MODE="0666", GROUP="plugdev"

# Red Probe
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="ad08", MODE="0666", GROUP="plugdev"
# RDB-Link
SUBSYSTEM=="usb", ATTRS{idVendor}=="21bd", ATTRS{idProduct}=="0001", MODE="0666", GROUP="plugdev"
# Red Probe+
SUBSYSTEM=="usb", ATTRS{idVendor}=="21bd", ATTRS{idProduct}=="0003", MODE="0666", GROUP="plugdev"

# Redlink
KERNEL=="hidraw*", ATTRS{idVendor}=="21bd", ATTRS{idProduct}=="0006", MODE="0666", GROUP="plugdev"
KERNEL=="hidraw*", ATTRS{idVendor}=="21bd", ATTRS{idProduct}=="0007", MODE="0666", GROUP="plugdev"
KERNEL=="hidraw*", ATTRS{idVendor}=="21bd", ATTRS{idProduct}=="0008", MODE="0666", GROUP="plugdev"

################
# NXP CMSIS-DAP
KERNEL=="hidraw*", ATTRS{idVendor}=="0d28", ATTRS{idProduct}=="0204", MODE="0666", GROUP="plugdev"
KERNEL=="hidraw*", ATTRS{idVendor}=="0d28", ATTRS{idProduct}=="0019", MODE="0666", GROUP="plugdev"
# NXP (Japan)
KERNEL=="hidraw*", ATTRS{idVendor}=="2786", ATTRS{idProduct}=="f00b", MODE="0666", GROUP="plugdev"

################
# KEIL CMSIS-DAP
KERNEL=="hidraw*", ATTRS{idVendor}=="c251", ATTRS{idProduct}=="f001", MODE="0666", GROUP="plugdev"
# ULINK2
KERNEL=="hidraw*", ATTRS{idVendor}=="c251", ATTRS{idProduct}=="2722", MODE="0666", GROUP="plugdev"
# ULINK-ME
KERNEL=="hidraw*", ATTRS{idVendor}=="c251", ATTRS{idProduct}=="2723", MODE="0666", GROUP="plugdev"

# FTDI adapters (i.e. USB serial ports)
# Generically set to world read/write. If not, ftdi driver aborts when trying to
# scan for debug adapters.
SUBSYSTEM=="usb", ATTRS{idVendor}=="0403", MODE="0666", GROUP="plugdev"

**************** End 85-lpcxpresso.rules *********************************

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue May 20 10:15:31 MST 2014
No, no, no, no no. DO NOT set the sticky bits. This is WRONG and (more importantly) DANGEROUS.

All you will need to do is to modify the udev rules so that the devices created by Debian when the devices are inserted are correctly set to world read+write. The udev rules supplied/installed work for Ubuntu/Fedora/Mint/OpenSuse etc. but are presumably not correct for Debian.

[lpcware]

Content originally posted in LPCWare by paul.rcom-software.com on Tue May 20 10:00:58 MST 2014
I have solved the problem and LPCXpresso now works normally.  The problem is the permissions of
dfu-util and crt* files do not allow non-root users to access USB devices. The solution is to go to
/usr/local/lpcxpresso_7.1.1_125/lpcxpresso/bin and set the sticky bits of those files as follows.
(i.e. This must be done as super user.)

    chmod 6755 dfu-util
    chmod 6755 crt*

I suspect this is an install script bug and it affects most version of Linux.  I will post the corrected
installation instructions to the group later.


Best Regards,

Paul R.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue May 20 08:59:50 MST 2014
The IDE works perfectly on supported platforms. Debian is not a supported platform.

I'm sorry, but I am unable to provide any further assistance  as I have already spent too long on this.

[lpcware]

Content originally posted in LPCWare by paul.rcom-software.com on Tue May 20 08:38:41 MST 2014
The IDE must not be configured correctly because if you try to run "FreeRTOS Blinky" in automatic debug
mode,  Redlink Server initialization of the LPC-Link2 module never finishes.  Instead, it keeps timing
out while trying to download LPC432x_Redlink_V4_26.bin.hdr.

There must be some kind of permission problem because dfu-util fails
when you run it manually. Perhaps the problem is the udev rules file
as you mentioned. Do you have an example of a rules file with correct
permissions ? My rules file is readable and executable by everybody
but writeable only by the owner--root. Also, a copy of the rules
file--85-lpcxpresso.rules, is attached to this note.

Here are the results of running the operations you specified.

This is the result of running dfu-util -l before doing anything:

dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found Runtime: [0x1fc9:0x000c] devnum=0, cfg=0, intf=0, alt=0, name="UNDEFINED"

This is the result of running the dfu-util download command as follows:

dfu-util -d 0x1fc9:0x000c -c 0 -t 2048 -R -D LPC432x_Redlink_V4_26.bin.hdr

dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Found Runtime: [0x1fc9:0x000c] devnum=0, cfg=0, intf=0, alt=0, name="UNDEFINED"
paulr@ebony:~$ dfu-util -l > /tmp/pre
paulr@ebony:~$ dfu-util -d 0x1fc9:0x000c -c 0 -t 2048 -R -D \
LPC432x_Redlink_V4_26.bin.hdr
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x1fc9:0x000c...
Claiming USB DFU Runtime Interface...
Cannot claim interface: could not claim interface 0: Operation not permitted

Best Regards,

Paul R.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue May 20 00:47:00 MST 2014
That output is completely normal.

The 'finished' indicates that the firmware has been downloaded into the device. At this point a USB reset is issued (-R) causing the device to boot and re-enumerate as an LPC-Link2. It is no longer a dfu device and so dfu-util is no longer able to read the dfu status, hence the final message.

I can't comment on your installation instructions as I do not have access to a machine running Debian.

I would point out that on a correctly installed systems:
[list]
  [*] you should never need to run dfu-util manually. The IDE takes care of this for you
  [*] similarly, you should not need to press the Boot Probe icon. The IDE will take care of this for you when you start a debug session.
  [*] dfu-util should not be run sudo
[/list]

For your information, to help you track down why the IDE does not see LPC-Link2 booting, the IDE does the following:

$ dfu-util -l # list dfu-bootable devices. Make sure the VID/PID are the expected ones for an unbooted LPC-Link2
$ dfu-util -d 0x1fc9:0x000c -c 0 -t 2048 -R -D LPC432x_Redlink_V4_26.bin.hdr # boot firmware into unbooted LPC-Link2
$ lsusb # parse the output, looking for the LPC-Link2 booted VID/PID

You might also want to check the udev rules to ensure these are setting the correct permissions for the supported USB devices on for Debian.