This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F280049: DSS/Linux/Jython/OpenHTF Linkage

Part Number: TMS320F280049


I'm trying to build out some production test infrastructure and I'm straight up not having a good time.  I've read all the wiki docs and all the forum posts I can find on this topic and I've tried everything I can think of.

Per the Jython instructions, I'm adding all the jars to my classpath using a shell script that also invokes my jython script:

#!/bin/bash

ccs_base_dir="/home/trey/ti/ccs1020/ccs/ccs_base"
dss_jar="${ccs_base_dir}/DebugServer/packages/ti/dss/java/dss.jar"
environment_jar="${ccs_base_dir}/DebugServer/packages/ti/dss/java/com.ti.ccstudio.scripting.environment_3.1.0.jar"
debug_engine_jar="${ccs_base_dir}/DebugServer/packages/ti/dss/java/com.ti.debug.engine_1.0.0.jar"
java_dir="/home/trey/ti/ccs1020/ccs/eclipse/jre"

export JAVA_HOME=${java_dir}
printenv JAVA_HOME

export CLASSPATH=${CLASSPATH}:${dss_jar}:${environment_jar}:${debug_engine_jar}
printenv CLASSPATH

jython singlecore.py

When this runs, jython can't find the jars and tell me "ImportError: No module named ti".

Alternatively, my debugging led me to try passing the class path in on the command line to jython:

jython -Dpython.path="${dss_jar}":"${environment_jar}":"${debug_engine_jar}" singlecore.py

This gets me a little further but I get the "SEVERE: Could not start server: DebugServer.1: Can not connect to DebugServer. null" error.  I've read the post from Ki that suggests only using the classpath way to get the jars in, but that's not working so I'm at a loss as to what's going on.  I have read a couple places that jython doesn't find stuff on the classpath but haven't found any resolutions.

My ultimate goal is to get DSS hooked up to OpenHTF in python so I can do production device programming and testing.  Any suggestions on how to fix the above issues or otherwise accomplish my goal?

Trey

  • Ok for some reason my original shell script that sets the classpath variable with export is working now even though I haven't changed anything in it.  I'm at a loss for why it didn't work in the first place.  I had monkeyed around with the version of jython I was using as well as tried putting the variable exports in bashrc.  When I had the exports in bashrc is when it started working and then I went back to using my script and removed those exports from bashrc.

    Any recommendations from SDO on RPC to use with jython so I can just make all my calls in normal python?  Are there any plans to add native python support to DSS? Jython seems pretty limited.

  • Hi Trey,

    Glad to hear that it is working now. I don't have an explanation on why it was not working before. Hopefully it was a hiccup that doesn't repeat again

    Trey German8 said:
    Any recommendations from SDO on RPC to use with jython so I can just make all my calls in normal python?  Are there any plans to add native python support to DSS? Jython seems pretty limited.

    There are (currently) no plans to add native support of python to DSS. Even Jython is not officially supported by DSS. Currently, only javascript is officially supported. Sorry.

    ki 

  • Thanks Ki.

    Well consider this a request from a customer.  Python support would open DSS up to a huge software ecosystem and would make it more accessible to customers.

    For others looking for a way to do this in the future:

    It's looking like my best option to link this up is going to be to use a library called Pyro4 which appears to work with both jython 2.7 and python 3+.  I'm going to wrap the DSS functions in a class in jython and then expose that wrapper class over the pyro RPC so I can access DSS in normal python.  Maybe I'll throw the code up on github when I'm done and post a link here.

    Trey

    FYI will click the answer button to close thread in a day or two once I have my wrapper complete and posted here for the other poor souls that might find this useful.

  • Trey German8 said:
    Well consider this a request from a customer.  Python support would open DSS up to a huge software ecosystem and would make it more accessible to customers.

    I will pass this feedback on to engineering. Python is certainly becoming more popular these days. Way back when DSS first came out, it was Perl that had the most requests to be supported with DSS. But things have certainly changed.

    ki

  • Ki,

    Soooo I've got a rudimentary implementation working using the Pyro4 RPC thingy I previously mentioned.  Wooohooo!  But I have a question regarding multi-target DSS.  For reference I have 4 wire JTAG hooked up to two F280049s that have been daisy chained and I'm using a XDS110

    Depending on how I perform DSS operations I see WILDLY different speed performance.    For instance, when I connect to both devices at the same time and then issue a memory.loadProgram to each target, it takes nearly 7 minutes to program both devices.  If I connect to a single target, program it, disconnect, and repeat with the other target, my total programming time is 3 minutes.  Why is there such a disparity when effectively I'm performing the same operations? FYI both of these test cases were performed will the RPC stuff completely turned off so as to isolate the issue.

    In case it matters, I'm using an ubuntu VM and i've given it 8 cores and 32gigs of RAM so I don't think it's hitting any compute limitations that would slow it down.

    Trey

  • As promised, here is my poorly cobbled together python DSS implementation.  I hope somebody out there finds this helpful!

    https://github.com/PML-Trey/TI-DSS-Python

  • Trey German8 said:
    Depending on how I perform DSS operations I see WILDLY different speed performance.    For instance, when I connect to both devices at the same time and then issue a memory.loadProgram to each target, it takes nearly 7 minutes to program both devices.  If I connect to a single target, program it, disconnect, and repeat with the other target, my total programming time is 3 minutes.  Why is there such a disparity when effectively I'm performing the same operations? FYI both of these test cases were performed will the RPC stuff completely turned off so as to isolate the issue.

    Can you run both scenarios with debug server logging enabled? Then zip the logs and attach to this thread. Also provide verbose DSS logs for each scenario also.

    Thanks

    ki

  • concurrent-slow.zip

    twosession-fast.zip

    This time the concurrent sessions took about 5 mins to execute. The two session serial approach took again took about 3 mins.

    Trey

  • Thanks Trey. I requested the engineering team to take a look. I'll pass on any updates to this thread as I get them.

    ki

  • I heard back from engineering. In summary, the debugger also periodically polls each non-debug core (like icepick) for status. This polling adds a bit of overhead. The more cores you are connected to at the same, the more polling that is required... which adds to the overheard. Hence why you see improved performance when connected to only once core at a time.

    With that said, the engineering team was surprised at how much overhead was added because of the polling. They felt that there was much room for optimization to greatly reduce the overhead. This is something that is being investigated.

    Anyway I hope this answers your question.

    Thanks

    ki

  • Trey,

    The overhead in the logs seems to be significantly larger than the same operation on other devices we've tested.  You mentioned this was on a linux VM - if you try the same programming operations not on a VM is the performance better?  If not, would you mind sending us the ccxml file you are using?

    Thanks,

    Darian

  • Darian,

    Here's the ccxml I'm using (extension changed because the forum software is dumb):

    <?xml version="1.0" encoding="UTF-8" standalone="no"?>
    <configurations XML_version="1.2" id="configurations_0">
    <configuration XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
            <instance XML_version="1.2" desc="Texas Instruments XDS110 USB Debug Probe_0" href="connections/TIXDS110_Connection.xml" id="Texas Instruments XDS110 USB Debug Probe_0" xml="TIXDS110_Connection.xml" xmlpath="connections"/>
            <connection XML_version="1.2" id="Texas Instruments XDS110 USB Debug Probe_0">
                <instance XML_version="1.2" href="drivers/tixds510icepick_c.xml" id="drivers" xml="tixds510icepick_c.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510c28x.xml" id="drivers" xml="tixds510c28x.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510cla2.xml" id="drivers" xml="tixds510cla2.xml" xmlpath="drivers"/>
                <instance XML_version="1.2" href="drivers/tixds510cs_child.xml" id="drivers" xml="tixds510cs_child.xml" xmlpath="drivers"/>
                <platform XML_version="1.2" id="platform_0">
                    <instance XML_version="1.2" desc="TMS320F280049C_0" href="devices/f280049c.xml" id="TMS320F280049C_0" xml="f280049c.xml" xmlpath="devices"/>
                <instance XML_version="1.2" desc="TMS320F280049C_1" href="devices/f280049c.xml" id="TMS320F280049C_1" xml="f280049c.xml" xmlpath="devices"/>
                    <device HW_revision="1" XML_version="1.2" desc="TMS320F280049C_1" description="" id="TMS320F280049C_1" partnum="TMS320F280049C" simulation="no">
                        <router HW_revision="1.0" XML_version="1.2" desc="IcePick_C_1" description="ICEPick_C router" id="IcePick_C_0" isa="ICEPICK_C">
                            <subpath desc="Subpath_1" id="Subpath_0">
                                <cpu HW_revision="1.0" XML_version="1.2" desc="C28xx_Subsystem1" description="C28xx CPU" deviceSim="false" id="C28xx_CPU1" isa="TMS320C28XX"/>
                                <cpu HW_revision="1.0" XML_version="1.2" desc="CLA1_1" description="CLA2 Accelerator" deviceSim="false" id="CLA1_0" isa="TMS192C2008"/>
                                <cpu HW_revision="1.0" XML_version="1.2" desc="cs_child_1" description="cs_child" deviceSim="false" id="cs_child_0" isa="cs_child"/>
                            </subpath>
                        </router>
                    </device>
                <device HW_revision="1" XML_version="1.2" desc="TMS320F280049C_0" description="" id="TMS320F280049C_0" partnum="TMS320F280049C">
                        <router HW_revision="1.0" XML_version="1.2" description="ICEPick_C router" id="IcePick_C_0" isa="ICEPICK_C">
                            <subpath id="Subpath_0">
                                <cpu HW_revision="1.0" XML_version="1.2" desc="C28xx_Subsystem0" description="C28xx CPU" id="C28xx_CPU1" isa="TMS320C28XX"/>
                            </subpath>
                        </router>
                    </device>
                </platform>
            </connection>
        </configuration>
    </configurations>
    

    I'll try to run a testcase in my native os (OSX) to see if the behavior improves and report back.

    Trey

  • Trey,

    A little bit more information.  The F28 is flashed by repeatedly writing the data to a RAM buffer and then running an algorithm on the target to write that memory to flash. Normally, the overall time is dominated by a combination of the memory transfer speed and waiting for that algorithm to complete.  However your log file shows that the operation is also significantly impeded by these status checks.

    The status checks are normally a few milliseconds at most.  However, in your case the status checks are consistently over 200ms, which is even longer than some of the larger memory transfers.   The status check reads several debug registers from the icepick which is less data as well as less JTAG operations compared to the memory transfers.  But the xds110 is optimized to do the memory operations with one USB transaction, whereas the status checks require a USB transaction per register.  Our assumption is thus that the VM is adding an overhead to the USB transaction and thus making the status checks significantly slower.  Locally, we can confirm that the load is significantly slower when using a VM, and that the time is dominated by different operations when using a VM.

    We can certainly put in a fix in the future to do these status checks less frequently, which will improve the VM performance.  But in general I would suggest moving off of a VM if you can.

    Darian

  • Darian,

    I never had any doubt that the VM was slowing things down. 

    Just consider this a data point for future implementation improvements.  My resources are somewhat limited right now and I have to develop software for all 3 major OSes so I'm stuck using VMs for now.  Ultimately the DSS stuff I'm developing will be on a dedicated test machine running natively so I'm not too concerned about speed at this point.  It just seemed odd that there was a performance difference between the two ways I was attempting programming.  

    Best,

    Trey