Code Red Probe+ problem under Linux

[lpcware]

Content originally posted in LPCWare by Steven_Buytaert on Mon Oct 25 04:35:21 MST 2010
Concerns Version: LPCXPresso 3.7.4_Beta [Build 97] under Linux [U]running as a VMWare Workstation guest OS.[/U] Linux version is Debian Lenny (5.0).
Problem: debugger (Red Code Probe+) gets disconnected during debugging session.

Hi,

I have included what I think is relevant log and trace information, collected from various sources, [U]below[/U]. Please see below for detailed logs. If not correct or if more info is needed, let me know and I'll post the required info).

I would be grateful if someone can provide some more insight into this problem.

Kind regards,

Steven

During debugging, after some time (a minute to some seconds), my target gets disconnected. Yielding the following error in the IDE console output:

16: Target error from status-poll: Ee(02). Not connected to emulator.

When I unplug and re-plug the Code Red Probe+, I get the following output from the "[B]crt_emu_lpc11_13_nxp -info-target[/B]" command line invocation: (note output in italic and wrapped)

[I]Ni: LPCXpresso Debug Driver v2.0 (Oct 19 2010 11:31:49)
GetModuleFileName path == /usr/local/LPCXpresso/bin/crt_emu_lpc11_13_nxp
Nc: Looked for vendor directory XML file in /usr/local/LPCXpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/LPCXpresso/bin/crt_directory.xml

Nc: Emu(0): Conn&Reset. DpID: 2BA01477. Info: FTTGMVVP A
Nc: SWD Frequency: 3000 KHz. RTCK: False. Vector catch: False.
Nc: Packet delay: 0  Poll delay: 0.
Ed:03: Failed on chip setup: Em(12). System rejected access at location 0x40048000 - verify Population of memory and peripherals
[/I]
I can start the debugging session OK, but after some time it fails with the error mentioned above in the IDE: 16: Target error from status-poll: Ee(02). Not connected to emulator. When I re-issue the "[B]crt_emu_lpc11_13_nxp -info-target[/B]" command, I get:

[I]Ni: LPCXpresso Debug Driver v2.0 (Oct 19 2010 11:31:49)
GetModuleFileName path == /usr/local/LPCXpresso/bin/crt_emu_lpc11_13_nxp
Nc: Looked for vendor directory XML file in /usr/local/LPCXpresso/bin/nxp_directory.xml

Nc: Found generic directory XML file in /usr/local/LPCXpresso/bin/crt_directory.xml

Ed:02: Failed on connect: Ee(05). No matching emulator found - make sure power is on and not in use already.
Et:31: No connection to emulator device[/I]

The last messages from the workspace/.metadata/.log file are the following:

!ENTRY com.crt.debugmgr 4 2 2010-10-25 13:21:11.949
!MESSAGE Problems occurred when invoking code from plug-in: "com.crt.debugmgr".
!STACK 0
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.AbstractStringBuilder.charAt(Unknown Source)
        at java.lang.StringBuilder.charAt(Unknown Source)
        at com.crt.debugmgr.mi.MICommandData.messageReceived(MICommandData.java:136)
        at com.crt.debugmgr.mi.ConsoleStreamer$ConsoleNotifier.run(ConsoleStreamer.java:94)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at com.crt.debugmgr.mi.ConsoleStreamer$ConsoleNotifier.notifyMessageReceived(ConsoleStreamer.java:82)
        at com.crt.debugmgr.mi.ConsoleStreamer.fireMessageReceived(ConsoleStreamer.java:269)
        at com.crt.debugmgr.mi.ConsoleStreamer.handleStream(ConsoleStreamer.java:339)
        at com.crt.debugmgr.mi.ConsoleStreamer.bufferReceived(ConsoleStreamer.java:238)
        at com.crt.debugmgr.server.StubServer$ServerNotifier.run(StubServer.java:89)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at com.crt.debugmgr.server.StubServer$ServerNotifier.notifyBufferReceived(StubServer.java:76)
        at com.crt.debugmgr.server.StubServer.firePacketReceived(StubServer.java:258)
        at com.crt.debugmgr.server.StubServer.dispatcher(StubServer.java:198)
        at com.crt.debugmgr.server.StubServer$1.run(StubServer.java:325)
        at java.lang.Thread.run(Unknown Source)

!ENTRY org.eclipse.debug.core 4 125 2010-10-25 13:21:11.950
!MESSAGE Error logged from Debug Core:
!STACK 0
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
        at java.lang.AbstractStringBuilder.charAt(Unknown Source)
        at java.lang.StringBuilder.charAt(Unknown Source)
        at com.crt.debugmgr.mi.MICommandData.messageReceived(MICommandData.java:136)
        at com.crt.debugmgr.mi.ConsoleStreamer$ConsoleNotifier.run(ConsoleStreamer.java:94)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at com.crt.debugmgr.mi.ConsoleStreamer$ConsoleNotifier.notifyMessageReceived(ConsoleStreamer.java:82)
        at com.crt.debugmgr.mi.ConsoleStreamer.fireMessageReceived(ConsoleStreamer.java:269)
        at com.crt.debugmgr.mi.ConsoleStreamer.handleStream(ConsoleStreamer.java:339)
        at com.crt.debugmgr.mi.ConsoleStreamer.bufferReceived(ConsoleStreamer.java:238)
        at com.crt.debugmgr.server.StubServer$ServerNotifier.run(StubServer.java:89)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at com.crt.debugmgr.server.StubServer$ServerNotifier.notifyBufferReceived(StubServer.java:76)
        at com.crt.debugmgr.server.StubServer.firePacketReceived(StubServer.java:258)
        at com.crt.debugmgr.server.StubServer.dispatcher(StubServer.java:198)
        at com.crt.debugmgr.server.StubServer$1.run(StubServer.java:325)
        at java.lang.Thread.run(Unknown Source)

!ENTRY com.crt.debugmgr 4 0 2010-10-25 13:21:23.728
!MESSAGE 16: Target error from status-poll
!SUBENTRY 1 com.crt.debugmgr 4 0 2010-10-25 13:21:23.728
!MESSAGE 16: Target error from status-poll
!SUBENTRY 1 com.crt.debugmgr 4 0 2010-10-25 13:21:23.728
!MESSAGE Not connected to emulator.

[lpcware]

Content originally posted in LPCWare by Steven_Buytaert on Tue Oct 26 00:11:50 MST 2010
Hi,

---

Quote:
I'm curious why you are using LPCXpresso for Linux, when you are already using Windows XP SP2, which is fully supported?

---

Several reasons:

- At home, I exclusively use Linux. Testing a certain setup under VMWare allows for 'experimenting' and evaluating some setups. When I work at home, I want the same IDE as at work.

- At work, for product support, we don't like to enforce an OS on to the customer.

- My personal feeling is that products supported for multiple OS'es have a tendency to become more solid and are better architected. It enforces you to think 'modular'which IMHO leads to better architecture. Same goes for supporting multiple JTAG probes.

- My 'natural' habitat is Linux (since '93), using Windows XP is a requirement of my 'customer'. (I work as a consultant). So the OS is not a religious issue, I'll use what is required/available/preferable, but being able to use the same IDE is an asset in such cases.

Kind regards,

Steven

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Oct 25 23:35:51 MST 2010
Thanks for letting us know.

I'm curious why you are using LPCXpresso for Linux, when you are already using Windows XP SP2, which is fully supported?

[lpcware]

Content originally posted in LPCWare by Steven_Buytaert on Mon Oct 25 23:00:49 MST 2010
Hi there,

Some more information and also some good news; all works fine it seems!

The VMware version is 6.5.4 (build 246459). After looking around in the VMWare knowledge base, I found the following link: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=774
The small hint I took from the page is about the "Frame Synchronization". Use a normal text editor to insert the following line in the <vmname>.vmx file [U][B]after you powered down[/B][/U] the virtual machine:

uhci.syncWriteback = "TRUE"

Apparantly, the VMWare USB driver will perform some optimization (frame collation??) that can improve bandwidth but could also wreak havoc on very frequent but small frames. This could upset the polling you mentioned in your reply.

After restarting the VM debugging now works or at least the small tests I tried, like downloading code, starting, stopping, adding watch expression and such.

As a side note, the VMware workstation runs on a Windows XP Professional Version 2002, SP3 Host OS (maybe this looks familiar to you ;-). I tried 2 different Linux distributions; an 'old' Debian Lenny (5.0) and a KUbuntu 10.10 (Maverick Meerkat) distribution.

Again, thanks for LPCXpresso on Linux and the support efforts!

[lpcware]

Content originally posted in LPCWare by Steven_Buytaert on Mon Oct 25 08:37:30 MST 2010
Hi,

Thanks for the info. I will post an exact version of both VMWare workstation and Host OS tomorrow (I'm not at work right now).

I appreciate and understand the fact that you can not support all linux distros. I would like to express my gratitude for the Linux port already. I have installed LPCXpresso under the same VMWare workstation but on an Ubuntu 10 release. I will check if that changes the situation.

I was also suspecting the virtual USB support from VMWare workstation, that maybe is too slow for the debug probe. I will have a look into the knowledgebase of VMWare itself to see if there are some settings that can be changed.

Kind regards for the support already given and will post a reply tomorrow morning.

Steven

[lpcware]

Content originally posted in LPCWare by CodeRedSupport on Mon Oct 25 05:18:36 MST 2010
I'm not sure we can help you, as this is not a supported environment (Debian Linux running under a VM). We know that Red Probe+ works when running natively on one of the supported distros.

When you run a target application, the debug driver polls the target to see if a breakpoint or other debug event has been occured. If the target does not respond, then this error message will be created. I suspect that the VM is either unable to handle the frequency of the polls, or that the VM USB translation is slowing things down so that the response isn't received in time.

However, if your provide us with some more information, we *might* be able to help further.
- what is you Host and version OS? (i.e. what are you running VMWare on)
- what is your target application doing when the disconnect happens?


Note: When this error occurs, you might find that you need to ensure all of the debug processes are terminated before starting a new debug session. If you cannot stop them from the Debug view, use a shell to look for processes arm-none-eabi-gdb and crt_emu_* and make sure they are not running.