Usage of multiple debug sessions on one PC

[lpcware]

Content originally posted in LPCWare by jantje1973 on Tue Dec 03 03:04:38 MST 2013
Hi

We want to use one computer that has
* multiple RedProbes connected
* multiple targets running (based on LPC1765)
* multiple LPCxpresso debug sessions running

If attached, LPCxpresso provides a list of attached RedProbes, but we see
that when using three RedProbes, the selected Probe is not necessarily the
one that is addressed. In other words: the wrong target is being debugged!

Has anyone experienced such behavior too?
* Is this a bug in LPCxpresso?
* Is there a solution or workaround available?

Additional information:
* LPCXpresso v6.1.0_164
* Windows 7
* Red Probe+

Thanks you in advance

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Jan 16 14:25:27 MST 2014

---

Quote: jantje1973
To test this I rebooted my laptop with nothing connected (assuming it resets the internal device list).
Once rebooted I connected my USB hub. Then I plugged in a Red Probe+ in the USB hub.
1 Emulators available:
0. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
And I connected another Red Probe+ to the USB hub.
2 Emulators available:
0. FTWX0N4LA    Red Probe+ A (Code Red - Red Probe+)
1. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
I then opened LPCxpresso where I have a project open. I select the "Program Flash" button and select the FTWINLUHA emulator. I select the .axf file I want to flash and press OK. Then the SWD LED on the FTWX0N4LA burns and the target connected to this emulator get flashed.
I attached the log, but I don't see anything strange in there (except that the FTWINLUHA emulator gets selected).

Then I attached both Red Probes+ directly to my laptop's USB ports:
2 Emulators available:
0. FTWX0N4LA    Red Probe+ A (Code Red - Red Probe+)
1. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
I then flash my target the same way as above without closing LPCxpresso. This time the SWD LED on the FTWINLUHA burns (correct!) and flashes the (correct) target.

Can it be that there is a timing issue? That crt_emu_cm3_nxp asks for the identification, but after that gets somehow redirected to the other emulator?

---

The internal device list used by LPCXpress is populated when you attempt to start a debug session, or use the flash dialog. There's no reason to reboot your machine to "clear" the list.

Do you see this problem only using the flash dialog? My original understanding of your problem is a debug session connected to the wrong emulator device. With regard to the flash dialog, the word of caution above applies. If the Flash dialog presents a "connect to" dialog, and you attach an FTDI device after the connections are displayed it's going to guarantee a failure.

Based on your latest observations, it's possible your USB hub has something to do with this problem. Can you substitute your USB hub with another hub and retest? Preferably a hub manufactured by a different vendor?

Regards,

LPCXpresso-Support

[lpcware]

Content originally posted in LPCWare by jantje1973 on Thu Jan 16 08:42:49 MST 2014
To test this I rebooted my laptop with nothing connected (assuming it resets the internal device list).
Once rebooted I connected my USB hub. Then I plugged in a Red Probe+ in the USB hub.
1 Emulators available:
0. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
And I connected another Red Probe+ to the USB hub.
2 Emulators available:
0. FTWX0N4LA    Red Probe+ A (Code Red - Red Probe+)
1. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
I then opened LPCxpresso where I have a project open. I select the "Program Flash" button and select the FTWINLUHA emulator. I select the .axf file I want to flash and press OK. Then the SWD LED on the FTWX0N4LA burns and the target connected to this emulator get flashed.
I attached the log, but I don't see anything strange in there (except that the FTWINLUHA emulator gets selected).

Then I attached both Red Probes+ directly to my laptop's USB ports:
2 Emulators available:
0. FTWX0N4LA    Red Probe+ A (Code Red - Red Probe+)
1. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
I then flash my target the same way as above without closing LPCxpresso. This time the SWD LED on the FTWINLUHA burns (correct!) and flashes the (correct) target.

Can it be that there is a timing issue? That crt_emu_cm3_nxp asks for the identification, but after that gets somehow redirected to the other emulator?

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Wed Jan 15 16:01:00 MST 2014
There's another possibility I can think of, and a note of caution. Once the LPCXpresso IDE populates it's internal device list from the FTDI driver (e.g. displays the "Connect to emulator" dialog), you cannot plug in another FTDI device before selecting a debug connection. The reason is attaching the new device has changed the effective order of the FTDI devices in the list. The "current" device order is still known to the driver, but LPCXpresso will not repopulate it's own list. Consider the following case.

In the first console display, LPCXpresso shows the order of two Red Probe+ emulators. No other FTDI device has enumerated.

Ni: LPCXpresso Debug Driver v6.0 (Nov 14 2013 01:02:32 - crt_emu_cm3_nxp.exe build 1216)
Pc: (  0) Reading remote configuration
2 Emulators available:
0. FTWN4280A    Red Probe+ A (Code Red - Red Probe+)
1. FTTMPRROA    Red Probe+ A (Code Red - Red Probe+)

The Red Probe+ emulators will occupy positions 0 and one in the LPCXpresso internal device list. This list is used to populate the "Connect to emulator" dialog.

I then attach a Gearmo USB-Serial adapter to my hub. This device is FTDI based. The FTDI driver returns the following device list:

C:\nxp\LPCXpresso_6.1.2_177\lpcxpresso\bin>crt_emu_cm3_nxp.exe -info-emu
Ni: LPCXpresso Debug Driver v6.0 (Nov 14 2013 01:02:32 - crt_emu_cm3_nxp.exe build 1216)
Pc: (  0) Reading remote configuration
2 Emulators available:
1. FTWN4280A    Red Probe+ A (Code Red - Red Probe+)
2. FTTMPRROA    Red Probe+ A (Code Red - Red Probe+)

The device indexes where the Red Probe+ devices reside have shifted by one position. The lesson here is, adding an FTDI based device after LPCXpresso has populated it's internal list is not going to work. Be certain this isn't contributing to the problem you report.

Regards,

LPCXpresso-Support

[lpcware]

Content originally posted in LPCWare by jantje1973 on Wed Jan 15 01:48:04 MST 2014
I have a USB hub connected. On that hub I connected 2 Red Probes+. (No more devices are connected, so the FTDI based USB-serial adapters I mentioned before is not connected)

So I first reconnected the USB hub and then reconnected the 2 Red Probes+ to the USB hub. (problem occurs)
The command gave this information about the emulators:
Ni: LPCXpresso Debug Driver v6.0 (Nov 14 2013 01:02:32 - crt_emu_cm3_nxp build 1216)
2 Emulators available:
0. FTWX0N4LA    Red Probe+ A (Code Red - Red Probe+)
1. FTWINLUHA    Red Probe+ A (Code Red - Red Probe+)
I don't see something something wrong so far.

Here an overview of what VID/PIDs I found for the Red Probes+ and the USB hub:
emulator FTWX0N4LA:
  -USB controllers
    *"Red probe+ A": USB\VID_21BD&PID_0003&REV_0700&MI_00
                                USB\VID_21BD&PID_0003&MI_00
    *"Red probe+ B": USB\VID_21BD&PID_0003&REV_0700&MI_01
                                USB\VID_21BD&PID_0003&MI_01
  -Ports (COM & LPT)
    *"Red Probe+ Trace Port (COM13)": FTDIBUS\COMPORT&VID_21BD&PID_0003

emulator FTWINLUHA:
  -USB controllers
    *"Red probe+ A": USB\VID_21BD&PID_0003&REV_0700&MI_00
                                USB\VID_21BD&PID_0003&MI_00
    *"Red probe+ B": USB\VID_21BD&PID_0003&REV_0700&MI_01
                                USB\VID_21BD&PID_0003&MI_01
  -Ports (COM & LPT)
    *"Red Probe+ Trace Port (COM17)": FTDIBUS\COMPORT&VID_21BD&PID_0003

USB hub:
  -USB controllers
    *"USB 2.0 MTT Hub": USB\VID_050D&PID_0237&REV_0100

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Jan 14 04:40:00 MST 2014
Please can you describe your USB layout - ie exactly what you have connected to your USB ports and whether they are connected directly or via hubs?

Can you also do the following:

1. Open a DOS command window.

2. Navigate to the LPCXpresso installation folder.
  'install_dir\lpcxpresso\bin'

3. Disconnect both your USB-Serial device(s) and the Red Probe+(s) from the USB ports, then reconnect in such a way that you see the problem.

4. Run the command : crt_emu_cm3_nxp -info-emu

Then please copy/post the text that this generates.

It might also be helpful if you can provide the VID/PIDs of the USB-serial convertors that you are using.

Regards,
LPCXpresso Support

[lpcware]

Content originally posted in LPCWare by jantje1973 on Tue Jan 14 01:53:48 MST 2014
Using LPCXpresso v6.1.2 didn't solve the problem. The problem still exists when I connect 2 Red Probe+ emulators on the USB hub. Even when selecting a different emulator, it gets redirected to first emulator in the list (that lets you choose an emulator).

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Thu Dec 05 15:12:50 MST 2013

This is nothing related to Red Probe+ firmware. There was one issue fixed in the latest LPCXpresso 6.1.2 release (announced earlier today) related to the combined use of an FTDI USB-Serial adapter and Red Probe+. Please install LPCXpresso 6.1.2 and let me know if this fixes your problem.

I can tell you I've connected 3 Red Probe+ emulators using independent LPCXpresso debug sessions in various combinations of powered hub and direct USB, and I cannot replicate the failure you've reported.

Regards,

LPCXpresso-Support

---

Quote: jantje1973

[snip]
Yes we use FTDI based USB-serial adapters too. These are mandatory for our solution.

---

[lpcware]

Content originally posted in LPCWare by jantje1973 on Thu Dec 05 00:38:58 MST 2013
Hello,

This serial number is displayed correctly, as you can see in the screenshot “threeRPSequence1.png”. The crt_emu_cm3_nxp tool is used for this (which also flashes the target). When one Red Probe+ is used, the dialog where you select your Red Probe+ device no longer shows up. However when you have multiple Red Probes+ connected it lets you choose one every time.

The problem is not 100% reproducable. First it worked, the selected probe flashed the target (with 2 Red Probes directly connected to my laptop and 1 in my monitor's hub that also has a mouse and a keyboard connected). Then I reconnected the probes and added another hub with other devices connected (see “threRPDeviceManager.png”). The first two probes flashed correctly, but the third one got redirected wrong.

Then I unplugged the devices, one by one, including the USB-hub, but it still got redirected. Also the connection sequence is tested, but still the same behavior (sometimes redirected to probe 1, sometimes to probe 2).

What has been detected is that when the wrong Red Probe+ is used to flash, the first probe in the list is used.

Also the probe that gets redirected has a different serial number comparing to the other 2. Could it be that somehow it different (newer) firmware?


Something else I tried is using the crt_emu_cm3_nxp command line tool directly by using the command: crt_emu_cm3_nxp -flash-load-exec "<axf-file>" -g -2 -e2 -vendor=NXP -pLPC1765 -s250 -flash-driver=LPC175x_6x_256.cfx -x <project>

The emulator is selected with the number after 'e', here the 3rd probe. This command also redirects to a different probe.


Yes we use FTDI based USB-serial adapters too. These are mandatory for our solution.

[lpcware]

Content originally posted in LPCWare by lpcxpresso-support on Tue Dec 03 09:57:20 MST 2013
We'll need more information to help you. At least post the dialog of the available emulator connections.

Unlike the LPC-Link1 emulators, each Red Probe+ emulator has a unique serial number. For example, here's the serial number of one of our units:

0. FTTMPRROA Red Probe+ A (Code Red - Red Probe+)

To ensure you're actually selecting the correct Red Probe+ connection, it's helpful to write the serial number on the outside of the unit to remove all doubt.

Each Red Probe+ emulator resides at a specific index (0 .. n) in the device list returned by the FTDI driver. Once you've established a connection to a Red Probe+, it should no longer show up in the list of available connections. Please confirm.

Depending on the sequence with which you connect each debug session, the remaining emulators may no longer be at sequential locations in the device list. To provide us more information, please alter your connection sequence if possible, and see if the results change.

One final question. Do you have any FTDI based USB-Serial adapters connected?

Regards,

LPCXpresso-Support