• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 31 subscribers
  • Views 594 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMDSEMU200-U: How to run 3 or more parallel DSLITE sessions in production programming?

Wolfgang Wendler TI
Intellectual 2100 points
Part Number: TMDSEMU200-U
Other Parts Discussed in Thread: UNIFLASH

Hi,

My customer uses three TMDSEMU200-U connected to the same PC to production program CC2652.

From the Uniflash CLI they invoke programming with the command dslite -c Config[x].ccxml -e [sw name].hex   (x=0, 1 or 2 depending which programmer to start).

This works if the programmers are invoked with a 4 seconds or more delay in between. Shorter delays, or no delay, causes issues and errors like ”no connection to XDS programmer”.

Is there a proper way to launch DSLITE in concurrent sessions on the same PC without the need for delays? The 8 seconds (4+4) extra delay in production programming is highly undesired.

Thanks and regards,

/ Wolfgang

  • 0
    TI__Guru**** 433591 points

    Hello Wolfgang,

    I am not able to reproduce this issue. I have three different launchpads connected to by PC - all with onboard XDS110 connections. I was able to use UniFlash CLI (dslite) to program all three in parallel without issue. I first had three separate command windows open, all with the command typed in and ready to go. Then I quickly pressed ENTER in all three within all withiin less than half a second. All three commands completed successfully. I then ran the commands from a script, with each command called asynchronously. Again no issues.

    -What UniFlash version is the customer using?

    -What is the host OS and version?

    -How is the customer invoking dslite?

    Thanks

    ki

  • 0 in reply to Ki
    TI__Intellectual 2100 points

    Hi Ki,

    Thank you for the reply. My customer will try this and also come back with the info you requested. He is currently out of office but will be back in a day or two.

    Thanks,

    / Wolfgang

  • 0 in reply to Wolfgang Wendler TI
    Prodigy 60 points

    Hi Ki

    Thanks for checking. On the test PC we use the following versions:

    - Windows 7 enterprise, 6.1 (SP1)

    - UniFlash 6.4.0

    The command string invoked by TestStand has the following format:

    "cmd /c dslite -c [configfile.ccxml] -e [hexfile.hex]"

    BR Morten

  • 0 in reply to Morten P. Moeller
    TI__Guru**** 433591 points

    I tried out UniFlash 6.4 on Windows 10 without issue. I then tried UniFlash 6.4 on Windows 7... and i noticed that sometimes one (or more) of the probes will get a connection or some other type of emulation error. It doesn't always happen, but it happens enough to be noticable.

    I'm not sure why it is an issue on Windows 7 and not Windows 10. My Windows 7 PC is a much lower performing PC so perhaps that is a factor. Again, the frequency of the issue is variable. I also tried this with XDS110. I will next try with XDS200 probes. What vendor probe is the customer using? Blackhawk? Spectrum Digital?

    Thanks

    ki

  • 0 in reply to Ki
    TI__Intellectual 2100 points

    Hi Ki,

    Thanks for following up on my customer's inputs. They are using the Blackhawk XDS200 programmer.

    Thanks,

    / Wolfgang

  • 0 in reply to Wolfgang Wendler TI
    TI__Guru**** 433591 points

    Thank you. I will try this with XDS200. I don't have three blackhawk XDS200 so I'll have to mix and match. It will take some time to set this environment up so I will not have an answer immedately.

    Does the still issue occur when run outside TestStand?

    Would it be possible to try on a Windows 10 PC?

  • 0 in reply to Ki
    Prodigy 60 points

    Hi Ki

    It sounds much like the same issue we experience. The behavior is the same if the dslite commands are issued outside TestStand (from a .bat file)

    Unfortunately we are forced to use a Win7 PC, as the application is an upgrade of an existing flashing station.

    BR Morten

  • 0 in reply to Morten P. Moeller
    TI__Guru**** 433591 points
    Morten P. Moeller said:
    Unfortunately we are forced to use a Win7 PC, as the application is an upgrade of an existing flashing station.

    Understood. I was just wondering if it was possible to temporarly try the environment on some Windows 10 PC as a test to confirm if it is specifically a Windows 7 issue as I am observing.

    I'll likely be able to setup my Win 7 test environment on Wednesday and have an update for you then.

    ki

  • 0 in reply to Ki
    TI__Guru**** 433591 points

    The issue seems more pronounced with XDS200. I was able to reproduce the issue on my Windows 10 laptop with three XDS200 debug probes connected to it. I believe the delay required to workaround the issue depends on the speed of the PC. My laptop is fairly powerful and a delay of 1.5 to 2 seconds was enough to avoid any connection failures. Unfortunately there does not appear to be any better workaround.

    I filed a bug for this. Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-10652

  • 0 in reply to Ki
    Prodigy 60 points

    Thanks for your investigation, Ki.

    I'll take a look on what's possible on the test PC, in order to free up as many resources as possible during the programming period.

    BR Morten

  • 0 in reply to Ki
    TI__Intellectual 2100 points

    Thank you Ki. I believe this resolves the issue as far as possible at this point. Appreciate you filing a bug report to hopefully have this addressed in a future SW release.

    I will mark this as resolved now.

    Morten, thanks for your input as well. Hope you can find a way to make the programming process a bit faster with your existing equipment. Not sure if XDS110 programmers might be an option as these seem to use less resources on the PC. Chances are the actual programming transfer time is longer with these vs XDS200 so there is no total gain after all?

    Kind regards,

    / Wolfgang

  • 0 in reply to Wolfgang Wendler TI
    TI__Guru**** 433591 points
    Wolfgang Wendler TI said:
    Not sure if XDS110 programmers might be an option as these seem to use less resources on the PC. Chances are the actual programming transfer time is longer with these vs XDS200 so there is no total gain after all?

    It is not always so clear cut in regards to debug probe performance comparison. There is some data in the below link which may be of interest:

    https://software-dl.ti.com/ccs/esd/documents/application_notes/appnote-debug_probe_performance_results.html#cc2652r1

    Thanks

    ki

  • 0 in reply to Ki
    Prodigy 60 points

    Our motivation for selecting the XDS200 was primarily due to the size. We have very limited space in the flashing fixture.

    Prior to the decision, we conducted a pre-study with both XDS110 and XDS200, but the issue was not seen at that time. Probably as the PC's used were Windows 10 stations with more resources available than the actual test PC.

    BR Morten

  • 0 in reply to Morten P. Moeller
    TI__Guru**** 433591 points
    Morten P. Moeller said:
    Probably as the PC's used were Windows 10 stations with more resources available than the actual test PC.

    Yes this is the case for me also. My WIndows 10 machine is a relatively current machine while my Windows 7 lab PC is over 12 years old. 

    That said, I cannot reproduce the issue at all on Windows 10 using XDS110 while I can with XDS200 (with a ~1.5 second delay working around the issue). On my Windows 7 PC I was able to occasionally see the issue even with XDS110 (I did not try with XDS200 on Windows 7 but I would image that I would need a longer delay than from my WIndows 10 PC). It appears that host connection check (debugging first establishing communication with the dbeug probe) with XDS200 takes longer than the XDS110, hence the issue is more pronounced with XDS200.