LPCXpresso1769 - can't debug under Suse11.2

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Tue Jun 21 12:45:54 MST 2011
I have a persisting debugging problem with a lpcxpresso 1769 board under Linux, specifically under OpenSuse11.2-x64. I've been searching
for similiar threads, and tried the hints, to no avail.

The source of problem seems to be the lpc-link.
After inserting the board, lsusb says:
[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 009: ID 0471:df55 Philips
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
localhost:/home/fm/dev/arm-lpc-code-red/bin #[/COLOR]

Specifically, lsusb for the lpc-link:

[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb -v -s 002:009

Bus 002 Device 009: ID 0471:df55 Philips
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
idVendor           0x0471 Philips
idProduct          0xdf55
bcdDevice            0.01
iManufacturer           0
iProduct                0
iSerial                 0
bNumConfigurations      1
Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
      bInterfaceSubClass      1 Device Firmware Update
      bInterfaceProtocol      0
      iInterface              0
      Device Firmware Upgrade Interface Descriptor:
        bLength                             7
        bDescriptorType                    33
        bmAttributes                        1
          Will Not Detach
          Manifestation Intolerant
          Upload Unsupported
          Download Supported
        wDetachTimeout                  65535 milliseconds
        wTransferSize                    2048 bytes
Device Qualifier (for other device speed):
bLength                10
bDescriptorType         6
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
bNumConfigurations      1
Device Status:     0x0000
(Bus Powered)
localhost:/home/fm/dev/arm-lpc-code-red/bin #[/COLOR]

This seems normal to me. It is identified as DFU adaptor.

But is this normal ?

[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # crt_emu_cm3_nxp --info-emu --wire=winusb
Ni: LPCXpresso Debug Driver v2.0 (Apr 1 2011 10:54:24)
0 Emulators available:

localhost:/home/fm/dev/arm-lpc-code-red/bin #
[COLOR=Black]
Then, I download the firmware to the lpc-link, exactly as suggested in
another[/COLOR] [COLOR=Black]thread. I need to do this as root, not sure if this o.k.:

[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # dfu-util -d 0x471:0xdf55 -c 0 -t 2048 -R -D LPCXpressoWIN.enc
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0471:0xdf55...
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
Found Runtime: [0x0471:0xdf55] devnum=9, cfg=0, intf=0, alt=0, name="UNDEFINED"
Claiming USB DFU Interface...
Setting Alternate Setting ...
Determining device status: state = dfuIDLE, status = 0
dfuIDLE, continuing
Transfer Size = 0x0800
bytes_per_hash=604
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
can't detach: Broken pipe
Resetting USB to switch back to runtime mode
error resetting after download: No such file or directory
localhost:/home/fm/dev/arm-lpc-code-red/bin #[/COLOR]

Albeit the error message, this is identical to the thread mentioned, so
I guess no problem here.
Then, lsusb says:

[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[COLOR=Red]Bus 002 Device 010: ID 1fc9:0009[/COLOR]
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
localhost:/home/fm/dev/arm-lpc-code-red/bin #
[/COLOR]

And, specifically to this device:

[/COLOR][/COLOR][COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb -v -s 002:010

Bus 002 Device 010: ID 1fc9:0009
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
idVendor           0x1fc9
idProduct          0x0009
bcdDevice            1.00
[COLOR=Red] iManufacturer           1 Code Red Technologies
iProduct                2 LPC-Link Probe v1.1         [/COLOR]
iSerial                 3 T1S6RGRIA
bNumConfigurations      1
Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              500mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass      0
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82 EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200 1x 512 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02 EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0200 1x 512 bytes
        bInterval               1
Device Qualifier (for other device speed):
bLength                10
bDescriptorType         6
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
bNumConfigurations      1
Device Status:     0x0000
(Bus Powered)

localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb[/COLOR]

It seems the firmware is downloaded properly.
Now I need to cycle power, because the device is 'busy' otherwise, and
when I try to start a debugging session, GDB times out.

However, after that, it is again a DFU adaptor, as before:

[COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
[COLOR=Red]Bus 002 Device 011: ID 0471:df55 Philips
[/COLOR]Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
localhost:/home/fm/dev/arm-lpc-code-red/bin # lsusb -v -s 002:011

Bus 002 Device 011: ID 0471:df55 Philips
Device Descriptor:
bLength                18
bDescriptorType         1
bcdUSB               2.00
bDeviceClass            0 (Defined at Interface level)
bDeviceSubClass         0
bDeviceProtocol         0
bMaxPacketSize0        64
[COLOR=Red] idVendor           0x0471 Philips
idProduct          0xdf55
[/COLOR] bcdDevice            0.01
iManufacturer           0
iProduct                0
iSerial                 0
bNumConfigurations      1
Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0x80
      (Bus Powered)
[COLOR=Red]    MaxPower              100mA
[/COLOR]    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass       254 Application Specific Interface
[COLOR=Red]      bInterfaceSubClass      1 Device Firmware Update
[/COLOR]      bInterfaceProtocol      0
      iInterface              0
      Device Firmware Upgrade Interface Descriptor:
        bLength                             7
        bDescriptorType                    33
        [COLOR=Lime]... (shortened, too much characters !)[/COLOR]
(Bus Powered)
localhost:/home/fm/dev/arm-lpc-code-red/bin #[/COLOR]

When I try to start a debug session, a message box "initializing LPC-Link v1.1" appears, superseeded by a timeout message box. I can opt to
show a boot log, but it's shortened to uselessness. I can see that it
tried to start dfu-util with the correct vendor/product id.
Finally I'm thrown out with a message box "Timeout waiting for LPC-link
v1.1 to initialize".

Finally, the same board (LPCXpresso) works fine under Windows, so
there is no hardware issue.

Can someone explain what am I doing wrong, and set me on the right track ?

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Mon Jun 27 04:48:09 MST 2011
Finally, thank you for this clarification. I wish I knew before...

And, as someone who had to give support to users some time ago, it's often surprising what 'crazy' ideas users have ;-)

@Luis Digital
[COLOR=Blue]> I've never used a PIC, but the 8051 has lots of compiler / simulators that run on Linux, even cross-platform using Java. And the best: Gratis
[/COLOR]
The context was a slightly different one.
I use almost exclusively Linux at home, and ARM controllers are my private field of interest.
At my 'day job', I use to develop software for those mentioned 8-Bit controllers under Win XP. I do not have the option to use another OS.
And, by the way, the tool chains cost some kilo-bucks, but are not less buggy compared to free software, or even more.
It is often a paradox. The higher the number of units a company wants to sell, the more arcane and buggy is the tool chain, and the more outdated
is the controller architecture (the PIC18 is basically a tuned end-seventies design).

Regards
Frank

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Mon Jun 27 01:12:25 MST 2011
Some comments in case anybody comes across this thread. These comments apply to Windows and Linux installs (except where stated).

[LIST]
[*]The installation directory is chosen for a good reason - it is available to all users of that computer. We strongly recommend that it is not changed, unless you really know what you are doing.
[*]The installers sets various permissions on directories to prevent accidental corruption of the install. These are 'root' or administrator privileges. Do not try to change these permissions or ownership.
[*]Do not try to place user data in the install directory: 1. When you uninstall, you can potentially lose your use data. 2. you need to be root/administrator to create data in those directories.
[*]In recent versions of Windows (Vista and Win7), Program Files is a protected directory that can normally only be written to by installation programs or administrators. DO NOT try to store user data in this directory (Windows will virtualize to a different directory). This is also the reason that we do not install to Program Files - the IDE caches data in the install directory and this will fail if store in Program Files
[*]LPCXpresso is a 32-bit application. If installing on a 64-bit version of Linux, the 32-bit compatibility libraries must be installed. No special action is required when installing on 64-bit versions of Windows.
[*]The LPCXpresso debug driver make very heavy use of low-level USB calls. On older Linux distributions, the USB drivers and/or libusb did not support this and so debug will fail for all sorts of strange reasons.
[/LIST]
Finally, due to the huge variations in features of the many different Linux distributions, we restrict support to a few known, well supported, well behaved distros, that we are able to test on. These supported distributions are listed on the download page. LPCXpresso may well work on other *recent* distros, but we cannot we cannot support you if it does not work.

Hope that helps

lpcware · ‎06-15-2016

Content originally posted in LPCWare by Luis Digital on Sun Jun 26 16:04:11 MST 2011
I've never used a PIC, but the 8051 has lots of compiler / simulators that run on Linux, even cross-platform using Java. And the best: Gratis.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Sun Jun 26 11:12:17 MST 2011
[SIZE=2]I found it here, another thread in this forum:

http://knowledgebase.nxp.com/showthread.php?t=1552
[/SIZE][SIZE=2][SIZE=3]
[SIZE=2]As it turns out in the thread, actually the crt_emu_* executable crashes, probably because of a buffer overflow when receiving an answer from this deamon about a local IP address...[/SIZE][/SIZE]

[/SIZE] [SIZE=2]I have been busy for two days, because I almost destroyed my PC configuration. I installed Ubuntu on a second HD, and debugging worked there, too. However, Ubuntu destroyed my MBR of a dual-boot system (SuSe11.2 + Win7 on the first HD). It was probably too late at night. Now I can boot either OpenSuse (11.2) or Win7, after reinstalling the appropriate MBR.

But I found out some other interesting things.
It is easy to mess up your (Eclipse) installation. First, I installed the LPCXpresso IDE in my home path. The idea was to keep different toolchains for similar controllers somehow together.
Second, I created a Workspace in this installation folder. This creates strange conflicts because of access rights, I guess. This suddenly dawned on my when I had to login as root to create a folder. At one point, I [/SIZE] [SIZE=2][COLOR=Blue]chown[/COLOR][/SIZE][SIZE=2]-ed the whole LPCXpresso folder to me as non-root user.
I once had this problem with Atollic TrueStudio (eclipse based IDE for STM32), when I created a workspace as a TrueStudio subfolder, alltogether located in "C:\Program Files\...". I never succeeded in building a simple example project, because of dozens of mysterious build errors. All errors disappeared when I created a new workspace away from "C:\Program Files\".

When I install the IDE in /usr/local/, as suggested, and create a workspace somewhere else, I can debug under OpenSuse 11.3.

This does not work on my old OpenSuse 11.0 system. It ends with the "[/SIZE] [SIZE=2][COLOR=Red]Remote communication error: Connection reset by peer" [COLOR=Black]issue. If I kill the nscd deamon, the launching of crt_emu_* just hangs and takes forever.

Once I fix my 11.2 PC (a desktop, the other ones are notebooks), I try it there, too. This is a 64 bit version, which might spell additional trouble.

[/COLOR][/COLOR][/SIZE][SIZE=2]
> I'm newbie in ARM and Eclipse IDE and don't ...

I would see myself in this category, too. Nothing unusual for someone asking a question in this forum.
And I wish I had more time to learn and use Linux - and I would be a little happier not having to use Windows to develop for PIC18 and 8051 controllers.[/SIZE]

lpcware · ‎06-15-2016

Content originally posted in LPCWare by FlySnake on Fri Jun 24 13:04:40 MST 2011

Quote: frame

Shutting down the nscd daemon, as suggested in another thread, did not help either.

Wow! In which thread did you find this? It helped me! Thank you so much :) Very strange behavior. nscd is just DNS caching service, how it could be dependent?
Since it works in my openSUSE 11.2, we can compare configurations and probably help you. I'm newbie in ARM and Eclipse IDE and don't know much about run/debug procedure yet, thus you ask anything about it in my OS.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Thu Jun 23 08:46:01 MST 2011
To amend my issues:

The problem persists under Suse11.3 (say, OpenSuse11.3; all my installations actually OpenSuse, but I'm to lazy to type ;-)
Here I end up with:
[COLOR=Blue]Error Launching Debug/...
02: Failed on connect: Em(02). MEM-AP is not selected[/COLOR]
Shutting down the nscd daemon, as suggested in another thread, did not help either.

Today I got hold of another machine, which has Qimo installed. This is an Ubuntu Linux version for children, my copy is based on kernel 2.6.32-31-generic.
Here, debugging works out-of-the-box.

So it seems Suse has a problem there.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Wed Jun 22 04:29:17 MST 2011
[COLOR=Blue]> The installer sets the SUID flags on the debug drivers (crt_emu*) and on dfu-util to overcome this problem. So, those files should be chmod 6755 with user root (or whatever is equivalent for your system) - but the installer should do that, unless you have changed something.

[COLOR=Black]You are right, the installation I refer to is broken in this regard.
the crt_emu* executable works, but the dfu-util complained about a missing libusb*.so.4. There --IS-- such a lib, and other tools find it. I blame a 32/64 Bit issue somewhere in the executable / lib chain.
Because I'm not the guro to solve it quickly, I downloaded a 64 Bit version of the dfu-util packet for Suse, and this works.

I have tried a second installation this morning on another machine, which is clean 32 Bit (Suse11.0), but only as root. At least, the dfu-util worked out-of-the-box.

To quote you on an earlier suggestion:
[/COLOR][/COLOR][COLOR=Blue]>My guess is that your USB drivers are not correctly rescanning the bus once LPC-Link as been booted (this is what the -R option on dfu-util is meant to do).[/COLOR]

I add the (slightly shortened) output from the dfu-util download from my original post:

[COLOR=Blue][COLOR=Black][COLOR=Blue]localhost:/home/fm/dev/arm-lpc-code-red/bin # dfu-util -d 0x471:0xdf55 -c 0 -t 2048 -R -D LPCXpressoWIN.enc
dfu-util - (C) 2007-2008 by OpenMoko Inc.
This program is Free Software and has ABSOLUTELY NO WARRANTY

Opening USB Device 0x0471:0xdf55...
Claiming USB DFU Runtime Interface...
Determining device status: state = dfuIDLE, status = 0
WARNING: Runtime device already in DFU state ?!?
...
bytes_per_hash=604
Starting download: [##################################################] finished!
state(8) = dfuMANIFEST-WAIT-RESET, status(0) = No error condition is present
Done!
can't detach: Broken pipe
Resetting USB to switch back to runtime mode
error resetting after download: No such file or directory
localhost:/home/fm/dev/arm-lpc-code-red/bin #[/COLOR][/COLOR][/COLOR]

This suggests to me, that the device was reset properly.

The lsusb afterward says:
...
[COLOR=Blue]Bus 002 Device 010: ID 1fc9:0009
Device Descriptor:
...
[COLOR=Red]idVendor           0x1fc9
idProduct          0x0009
[/COLOR]bcdDevice            1.00
[COLOR=Red] iManufacturer           1 Code Red Technologies
iProduct                2 LPC-Link Probe v1.1         [/COLOR]
iSerial                 3 T1S6RGRIA                   [/COLOR]
...

The vendor and product id have changed, so this seems right to me.
(As a comment, my knowledge of USB internals is really shallow).

I continue to monitor the "Debug problem LPC1769 Linux" thread, perhaps I find an answer there.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jun 22 03:52:43 MST 2011

Quote:

At first, I have to resolve an access rights issue, I think. The download to the lpclink fails because I do not (yet) have write access to the USB bus as normal user.

The installer sets the SUID flags on the debug drivers (crt_emu*) and on dfu-util to overcome this problem. So, those files should be chmod 6755 with user root (or whatever is equivalent for your system) - but the installer should do that, unless you have changed something.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by frame on Wed Jun 22 02:46:43 MST 2011
Hello, thanks for the quick response.

[COLOR=Blue]> As I am sure you have read, Suse is not one of the supported platforms, although we have had reports that LPCXpresso works on [B]Open[/B]Suse 11.3.[/COLOR]

I did read this. However, I've seem similiar problems with (at least) other versions of
Suse from 11.0 to 11.4.

[COLOR=Blue]> 1. After DFU booting LPC-Link, you CANNOT power cycle as that loses the image you just booted - LPC-Link contains an LPC3154 which is a RAM only part.[/COLOR]

I guessed it, but it is nowhere explicitly decribed in the LPCXpresso doc. I skipped the LPC3154 ref. manual...
At least I know now how it works.

[COLOR=Blue]>2. LPCXPresso is reporting a timeout because it never sees LPC-Link appear as a device (it runs lsusb and looks for a vid/pid of 1fc9:0009).
>
>My guess is that your USB drivers are not correctly rescanning the bus once LPC-Link as been booted (this is what the -R option on dfu-util is meant to do). I suggest you look to see if you can find a way to force your USB drivers to rescan the bus after LPC-Link has been booted.[/COLOR]

This is probably correct.
Actually, I came a step closer this morning. When starting the IDE as root user, the 'initialize lpc-link v1.1' - step succeeded. But then I got stuck with an error Message:
"[COLOR=Red]Remote communication error: Connection reset by peer[/COLOR]" (actually my translation).

At first, I have to resolve an access rights issue, I think. The download to the lpclink fails because I do not (yet) have write access to the USB bus as normal user.

That "Connection reset by peer" issue is the same as reported in the thread "Debug problem LPC1769 Linux", so I posted my observations there and hopefully get an answer.

lpcware · ‎06-15-2016

Content originally posted in LPCWare by CodeRedSupport on Wed Jun 22 01:07:24 MST 2011
As I am sure you have read, Suse is not one of the supported platforms, although we have had reports that LPCXpresso works on [B]Open[/B]Suse 11.3.

A couple of points:
1. After DFU booting LPC-Link, you CANNOT power cycle as that loses the image you just booted - LPC-Link contains an LPC3154 which is a RAM only part.

2. LPCXPresso is reporting a timeout because it never sees LPC-Link appear as a device (it runs lsusb and looks for a vid/pid of 1fc9:0009).

My guess is that your USB drivers are not correctly rescanning the bus once LPC-Link as been booted (this is what the -R option on dfu-util is meant to do). I suggest you look to see if you can find a way to force your USB drivers to rescan the bus after LPC-Link has been booted.