LAUNCHXL2-570LC43: Code Composer Studio running multiple sessions on same PC, with different projects code base

Hi,

I tested this issue using two boards RM46 and TMS570 with two different workspaces, and i run UART example on each board. I didnt see any issue.

I tested this in my CCS  Version: 11.2.0.00007 

Can you please let me know your CCS version?

--

Thanks,

Jagadish.

I tried CCS Versions 10.0.0, 10.4.0, 11.2.0, and 12.0.0 and they all have the same issue.  I thought it may be a problem with compatibility between CCS and the firmware on the XDS 110 probe (since CCS upgrades often require XDS 110 probe firmware upgrades), but that doesn't seem to be the case.

I'm using two TMS570LC43 boards, and they are very symmetric/identical.  I suspect that CCS ," when used on one PC for two boards, can't tell" which board is which, and hence gets confused.  I do know the COM ports on the PC sometimes "swap" for no obvious reason (maybe if one board is powered off and on, in different order with the other, etc.).  Sometimes, when I think I should be using board A, CCS ends up using board B.  I've had to use the on-board LEDs to show which board is which.  I think the USB and serial stuff on Windows are not good at retaining identity, perhaps because they don't have identifiers (serial ports, certainly).

In any case, I just hooked up another PC to the second board and everything works fine (as expected).  This set-up gets rid of the personality confusion.

If you have a chance to run on two TMS570 boards (rather then a RM46 and a TMS570), please try your experiment again.  I'm curious if you would see any "identify crises" problem.

Thank you very much.

Hi Peter,

Right now i don't have two identical boards, i will check with my colleagues whether they can help me or not?

--

Thanks,

Jagadish.

Hi,

No urgency, as I can work fine with 2 PCs on 2 boards right now.  If you can, please try the TMSXL2-570-LC43, as that's the board I'm using.

I don't know how "different" the two projects on the two boards have to be for the probe collision to happen,  My projects are substantially different, having been developed independently.  When I run the same project on the two boards, and do minor mods on the code, flashing it only on one of the boards, the probe/COM controls generally work fine.

It'd be nice if a single PC could run multiple sessions of CCS and control multiple boards, regardless of what project each board runs, but this is a wish-list rather than must-have.

Thank you.

Peter Lu said:

I'm using two TMS570LC43 boards, and they are very symmetric/identical.  I suspect that CCS ," when used on one PC for two boards, can't tell" which board is which, and hence gets confused.

With the XDS110 debugger on a TMSXL2-570-LC43 it should be possible to specify which XDS110 (and thus launchpad) to use for a project by specifying the serial number in Target Configuration - see Multi-probe debug for XDS110

See also Finding and updating the serial number

Yes.  I know.  But the CCS+XDS110 don't strictly adhere to this pairing, as I believe I mentioned before.

CCS will "hunt" for an available XDS110 when it needs/wants to.

For instance, suppose I set up CCS_instance1 to run with XDS110_probe1, and then CCS_instance2 to run with XDS110_probe2.  Then I shut down CCS_instance1 and then CCS_instance2.  If I then start CCS_instance2, instance2 will end up hooked to XDS110_probe1.  Then, if I start CCS_instance1, instance1 will hunt for a XDS110 and end up with XDS110_probe2 (since probe1 is already in use).

It's just some quirk of the CCS and debug probe set-up.

Thanks.

Hi Peter,

I ran two CCS sessions with two identical RM57 boards in debug mode

Here i ran the UART examples with two different data's, and i verified for long time and i don't see any issues. I mean both boards are working properly.

--

Thanks,

Jagadish.

Hi, Jagadish,

I've mentioned that running the "same" project on the 2 XL2-570LC43 boards works fine for me.  It's when the 2 boards are run with _different_ projects (as different as possible, with no common ancestor) that the debugging mechanisms fall apart.

Please try running two totally different projects, not the same project with some differences in data.

Also, make sure you _debug_ the two (different) projects (by setting/hitting/stepping breakpoints, etc.), not just load them and run them, since the failures I see are significantly related to the _debugging_ process.

Also the RM57 is a different board from the XL2-570LC43, so you may not see what I see.

Thank you very much.

Hi Peter,

I tried with totally different projects now, i.e. One board with RTI LED Blinky code and other one is UART. Also i tried setting/hitting/stepping breakpoints conditions also. 

I never faced any issues, i am able to debug both of the boards properly, I didn't face any problems in debugging process.

--

Thanks,

Jagadish.

Hi, Jagadish,

Thank you so much for performing these tests, to help me determine what is the cause(s) of the problems I see.  The general failure symptoms are the CCS-to-XDS110 connection and the COM port (canREG1) sharing the USB cable with the XDS110 chokes (stops running/interacting,  but can be resurrected by closing Putty session and reopening a new one).

With your input, I'm now thinking this CCS-probe/terminal behavior is simply related to the power problem we've been seeing in the last 2 weeks or so.  IOW, it may just be coincidental that what I perceived as the inability of one PC handling two Launchpads is really due to insufficient power.  When I started using one PC per Launchpad, the symptoms go away (at least to get running), but that may just be the situation that each Launchpad was now getting some more power.

You are unlikely to see any power issues with the Launchpads since the projects you run are very small, consuming very little power for very little time.  One of the things we are/were doing is running a CAN channel at 56% duty cycle, which is showing the Launchpad crashing randomly after some 1+ hours.  When I back down the duty cycle to 10%, the set-up will run 24+ hours.  My set-up has the Launchpad running off USB3 power, which supposedly provides 900mA, or 4.5Watt of power from the source (PC or USB hub).  We are doing experiments with power sources for the Launchpad, and should be able to tell better how the power factor affects the Launchpad.

My previous experiences with small boards, including Raspberry PIs, always had the boards directly powered from some dedicated power supply (that used a "USB" connector that was only used for powering, not functional).  Debugging and comm facilities used a separate USB cable.  That's why I was somewhat impressed by the Launchpad at first glance, but maybe the limitations are now showing.  With the RaspPI 3s, a 2.5A (12.5W) power supply was required, and for the RaspPI 4s, a 3A (15W) power supply was required, which is significantly higher than the 4.5W the Launchpad gets.

Could you describe to me how your Launchpads are powered?   I'm guessing that you simply use the USB cables connecting to the PC (or USB hub), providing them 4.5W each.

I did just try two different Launchpads running different projects while connected to one PC, and this worked.  The CAN experiment for this set-up was using the 10% duty cycle and hence not power-starved.  Oftentimes, correlating failures with causes is difficult.

BTW, the CCS-to-XDS110 "switching" still happens.  IOW, even if a project designates that it uses XDS110_probe2, it will end up using XDS110_probe1 if probe1 is available (not in use by another CCS session).  I can live with this behavior, since my set-up is "symmetrical," where I don't care which board (of 2) runs what project (of 2).

Thank you very much.

Hi Peter,

Could you describe to me how your Launchpads are powered?   I'm guessing that you simply use the USB cables connecting to the PC (or USB hub), providing them 4.5W each.

Yes your guess correct and i did use the USB cables connected directly to PC. And i think you are right about power, this issue might be due to power only and your testing also indicating the same.

--

Thanks,

Jagadish.

Hi, Jagadish,

After messing around with out "lab" set-up that has a different power-supply scheme, we kept encountering the XDS110/COM problem, as before with USB-powered (running different images on the 2 Launchpads, etc.)  So, it didn't seem the CCS-to-probe connection issue was power related.

Our hardware guy discovered the setting for the JTAG speed, which is set to 5.5MHz by default.  We tried using a lower value, at 2MHz, and, _voila_, the debug probe no longer had the connection problems.

So, right now, we believe using a lower JTAG speed fixes the problem with using 2+ Launchpads from the same PC.  We did discover that PC speed also matters, as when we used a performance (8 cores, 32GB RAM) PC, connections happened much more cleanly/quickly than when we used a outdated (2 cores, 16GB RAM) PC.  So, we'll keep this in mind.

I noticed the selection of XDS110 probe by serial number.  I recall seeing someone post something on this many weeks back, but lost track of this (as things were working for me).  Right now, both of my CCS sessions have the serial number set to "HL5LC400."  How do I get the serial numbers of the XDS110 on the 2 Launchpads?

Thank you very much.  I'll post more as we make any additional related discoveries.

Peter Lu said:

How do I get the serial numbers of the XDS110 on the 2 Launchpads?

If you run the following, it will report information about each connected XDS110, including their serial number:

<ccs_install_root>/ccs/ccs_base/common/uscif/xds110/xdsdfu -e

I.e. plug one launchpad in at a time and run the comment to get it's serial number.

The XDS110 Debug Probe User's Guide has more information on the xdsdfu utility.

Thanks for this info.

I set up the serial numbers for my XD110s...

+++

C:\ti\ccs1200\ccs\ccs_base\common\uscif\xds110>.\xdsdfu -e

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2019 Texas Instruments Incorporated. All rights reserved.

Scanning USB buses for supported XDS110 devices...

<<<< Device 0 >>>>

VID: 0x0451 PID: 0xbef3
Device Name: XDS110 Embed with CMSIS-DAP
Version: 3.0.0.20
Manufacturer: Texas Instruments
Serial Num: HL5LC400
Mode: Runtime
Configuration: Standard

<<<< Device 1 >>>>

VID: 0x0451 PID: 0xbef3
Device Name: XDS110 Embed with CMSIS-DAP
Version: 3.0.0.20
Manufacturer: Texas Instruments
Serial Num: HL5LC401
Mode: Runtime
Configuration: Standard

Found 2 devices.

C:\ti\ccs1200\ccs\ccs_base\common\uscif\xds110>

+++

And in my two CCS sessions, configured the Target Configurations to use HL5LC400 and HL5LC401 respectively.

I'm currently running two workspaces both pointed to the same project file system (where code exists).

However, when I look at the Target Configurations, both CCS sessions have HL5LC401 listed in them now.  So, it seems this parameter is stored in the one CCS " project file system rather than in the two project workspaces (or something like that).

My test has been running stably for the last several hours.  But don't know if the serial number mechanism is actually in effect or not.

In addition to using the 2MHz JTAG clocks, since the probe+COM USB facility seemed fragile (and Putty hung up after some 2 hours), I changed sciREG1to use 115200 baud instead of 230400 baud, which seems to help considerably.  I have not seen a sudden vectored interrupt (undefERROR, prefetchERROR, etc) failure, but did see a sudden reset.  So, lowering clocks seems to increase stability, or at least run longevity.

I've added using the probe serial number to lock CCS to particular XDS110 probes.  Not sure if this is actually being used in operation or not, but test is still running stably so far.

Indeed, if I use the serial number (set differently on the 2 probes), the CCS configuration information is saved in the "project file system (code base)" rather than the "project workspace," so since I use two workspaces (for the two Launchpads) pointing to the same "project file system," I end up having to manually change the Target Configuration for (at least one of) the workspace to use the appropriate probe.

This is a little cumbersome, and somewhat defeats the purpose of designating the probe by unique identifier (serial number), as the probe selection cannot be saved with the workspace (which specifies the specific functionality, and hence the board that the workspace should be using).

Please let me know if there is any way around this.

Thank you very much.

Looks like it's as simple as having two separate Target Configurations set up, and the two workspaces can have different Target Configurations selected as Active.