TICSPRO-SW: GUI interface not loading

Hi Eduardo,

Can you post the ErrorLog00.txt file in that folder?

We recently did a lot of updates to TICS Pro in 1.7.5.0 revision, including a new revision of the USB2ANY DLL... given where the GUI is getting stuck, it seems likely to me that there's some issue related to USB2ANY. This is a long shot, but can you try renaming or removing the USB2ANY.dll file in that folder, and replacing it with the older version below?

USB2ANY.dll

Regards,

Derek Payne

A second thought occurs: do you have a second monitor or other zone set up where something could be getting obscured? The new USB2ANY revision should pop up a dialog when a USB2ANY from the older firmware revision is connected during startup, and I'm wondering if this dialog is showing up on a different (potentially primary) monitor, or if the popup has been obscured by the splash screen. Does ALT-TAB show any other popups in this state?

Hi Derek,

I tried to replace the USB2ANY.dll but this does not solve the issue. In the ErrorLog00.txt there is no error appearing.

Regards,
Eduardo

There is no ther popup appearing. I double-checked this.
Any other ideas?

Hmm, peculiar.

I have two things to try: clearing the settings file that stored the previous LMX2572 profile data, and picking a different startup device.

First, make sure every TICS Pro process has been terminated.

To clear the profile data for LMX2572, navigate to C:\ProgramData\Texas Instruments\TICS Pro\Configurations\Devices\PLL + VCO\LMX2572\LMX2572. From within this folder, there should be a file called LMX2572.tcb; delete this file and try restarting TICS Pro.

If that doesn't work, we can try changing the startup device. Once again, make sure every TICS Pro process has been terminated. Then, in C:\ProgramData\Texas Instruments\TICS Pro\Configurations, there is a file called TICS Pro.ini. It should look something like this.

TICS Pro.ini

In your file, under the [SETUP] section, there's a key DEVICE_NAME00=LMX2572; try changing it to a device you've never used (maybe LMX2820) and starting TICS Pro again.

My hope is that there's something weird about your specific LMX2572 profile that's throwing you for a loop.

Just to clarify the timeline, did you install the new version of TICS Pro and then immediately encounter difficulty? Or did you install it a week ago, use it without issues for a week, and then spontaneously run into this problem? It's not clear from your initial post.

Hi Derek,

Thank you for your answer but this also did not work.
So just to clarify:

- I installed TICS-PRO a week ago. I was able to launch and program my device. I also was able to automate the whole thing using Python:

      pll = win32com.client.Dispatch("TICSPro.ActiveX")
      pll.Initialize(r"C:\Program Files (x86)\Texas Instruments\TICS Pro"))

- I turned off my PC and then this monday I cannot launch anymore TICS PRO. I tried to reinstall and it still does not work.

Maybe you have other ideas now that I showed the big picture

Eduardo

Eduardo,

In light of reinstall not fixing the problem, I'm tempted to say this isn't a file integrity issue; just in case, you can check the MD5 of the installer to be sure it was downloaded correctly. The file "TICS Pro Install, Ver 1.7.5.0, 20-Apr-2022.exe" should have MD5 checksum of 357c1180914ff892561385ff62f8674d. A quick python script to check the MD5 checksum is included below.

import hashlib
m = hashlib.md5()
with open("TICS Pro Install, Ver 1.7.5.0, 20-Apr-2022.exe",'rb') as f:
    m.update(f.read())
assert m.hexdigest() == '357c1180914ff892561385ff62f8674d'

So to confirm, you are now unable to launch by any means (double-clicking, python ActiveX initialization, etc)? In other words, the issue does not solely affect ActiveX launching?

We've run into trouble with ActiveX in the past which has led us toward deprecating the interface soon (see the TICSPro_TCP.py file included in the installer for the suggested replacement through socket servers, which also helps avoid issues with 64-bit processes). I've admittedly never seen a case where the application just refuses to get past the raw registers stage entirely... I'm kind of baffled.

I have a previous install version (1.7.4.1) from before the most recent revision, linked below. Maybe we try back-revisioning to 1.7.4.1 and this solves the issue?

<File 'snac072a0.zip' was removed to comply with export restrictions. Normally the TICS Pro download page prompts for export control compliance (military or civil use, automatic screening). Since you successfully downloaded the original installer, I had no issues providing a previous version to you - but I cannot leave it on E2E indefinitely.>

Hi Derek,

I ran the python script you suggest and I get m.hedigesti() to 'c91c9be8ad981bebe23be01c53366fc3' which is not the same value you suggest.

I tried uninstalling TICS pro and going to the back revision you have and the same problem is there. Instead this time the windows keep showing '... Loading Device'

Cheers,
Eduardo

Eduardo,

Apologies for the delay, I was OoO yesterday.

I am very glad I asked you to perform the MD5 on the installer. The hash values of these files should absolutely match. I just downloaded TICS Pro again from TI.com to confirm, and I computed the exact same hash. Your version of the installer is different than the one I just downloaded from TI.com, which likely means that the install file has become corrupted. I see two possible explanations, one of which is directly testable:

1. Something happened during downloading of the installer file, and the zip file wrapping the installer was downloaded in an incomplete state. This would be weird, but not unheard of. It is directly testable: you can run the same script above but with the file 'snac072ap.zip' which you downloaded from TI.com, and confirm that the zip file hash matches: 5ec820e8f183a75a0cd718481bfdb69e.
   1. If the hash matches, your download from TI.com was not corrupted, implying another explanation.
   2. If the hash doesn't match, the download was corrupted and now there should be no expectation that TICS Pro will work properly.
   3. Incidentally, the hash for "TICS Pro Install, Ver 1.7.4.1, 04-Mar-2022.exe is 2ad041d120153acd1b81fc13b614da0f. 1.7.5.0 added more detail on the process in the splash screen, but they're likely stalled at the same point - I think if the previous revision is still not working after installing over the new version, and the hash for the previous revision is correct, there must be another issue preventing startup - continue to explanation 2. 
2. Something happened during or after extraction of the installer file, which altered the data of the installer binary or some dependency. There are a number of reasons this could have occurred, including a bug in the extraction program, a program modifying the installer data after extraction, a hard drive read/write failure that flipped some bits, some system dependency in the .NET Framework 4.5 libraries bundled with the OS becoming corrupted, etc. This explanation implies something more fundamental is wrong with the computer itself - you may have corrupted data for the zip extraction tool in your OS install, you could have a hard drive/SSD failure or bitflips that are not being successfully observed and flagged by the OS, there could be some other process (malicious, antivirus, etc) which is modifying binary installers... the list goes on. I'd put data corruption somewhere on your disk as the most likely of this category of issues, because you described things working until a restart, and because more than once I've had mass storage issues pop up between power cycles on some of my machines. And the fact that neither 1.7.4.1 nor 1.7.5.0 TICS Pros are working, and they seem to be failing in the same place, indicates to me that something common to both executables is causing the application to stall; the most likely candidate is a call to a .NET Framework 4.5 function, so maybe the binary data for .NET Framework 4.5 somehow got corrupted. I'd advise backing up any data on that machine, running the system file checker tool for your Windows install, and taking whatever other measures to investigate for systemic issues.

Regards,

Derek Payne

Dear Derek,

I tried to run the hash in the .zip and the hash matches.
Concerning a potential problem with the computer, I have the same issue with two completely different machines and therefore I would rather conclude that there is an issue with TICS PRO.

Regards,
Eduardo

Eduardo,

Eduardo Mendes said:

I tried to run the hash in the .zip and the hash matches.

Which specific file was this? Are you saying that you actually do have accurate hash for 1.7.5.0 installer?

Eduardo Mendes said:

Concerning a potential problem with the computer, I have the same issue with two completely different machines and therefore I would rather conclude that there is an issue with TICS PRO.

Out of the several hundred instances of people downloading and installing 1.7.5.0, you are the only person reporting this issue - something about your machines uniquely is affecting TICS Pro's operation. If I'm interpreting your comment above correctly, it sounds like none of your installer files were corrupted, so I think we can eliminate that possibility. But there might still be ways for two "separate" machines to encounter the same issues without the root cause being tied to TICS Pro itself:

• The machines are running the same VM image of windows, and the image is corrupted
• The machines are loading your account's server-side info to individual thin-clients, and there is an issue with the backend server data integrity
• A windows patch common to your organization was rolled out that impacts some piece of .NET Framework functionality and prevents TICS Pro from running
• Some third-party software common to both machines (e.g. antivirus) is intercepting application execution at the same point for some reason (but I consider this unlikely even among these kind of possibilities)

I don't know the details of your setups, so maybe none of these possibilities is valid. It is entirely possible that this is a TICS Pro application issue, and for whatever reason it has only emerged due to some common configuration of your machines.

In any case, we're in a tough spot - we've exhausted the straightforward debugging options. I might be able to provide you with debug symbols, and we could try attaching WinDbg, pulling a stack trace to figure out where specifically you're getting stuck, etc. I'd need time to work out how to do this, and time to provide clear instructions for you... we'd obviously be asking a lot from you, and we would likely need to move support from E2E to something more suitable. I can understand if this is more than you want to sign up for.

Still, I'd like to provide you with some way to use our software resources again, even if that ultimately involves offering an alternative. As an example, I know we have some internal tools in python which fulfill similar functions to TICS Pro (API commands for automation) - we might be able to provide one of these to you. Let me know if you'd prefer that instead of (or even in addition to) trying to debug the application.

Regards,

Derek Payne

Hello Derek,

thanks for your answer. For my needs, if I have python commands that I can write to the registers of the PLL that would be enough.

Eduardo