UNIFLASH: Linux desktop application sporadically stuck

Hi,

I have similar problem with UniFlash - maybe even more serious. I still have no installation that works.

What distribution and version of Linux did you use?

Regards,

Piotr Romaniuk

Nicolas,

Nicolas J. said:

OS: Fedora Linux 39

Please note that CCS/UniFlash tools are only officially supported on certain Ubuntu distributions. That does not mean that it will not work with other distributions, but we will be limited in the amount of support we can provide. Given the sporadic nature of the issue, it will be hard to provide any concrete solutions. When the issue occurs, it sounds like the GUI is hung (non-responsive?). Do you have to resort forcibly terminating UniFlash and restarting? Does the restart usually resolve the issue?

Thanks

ki

Piotr Romaniuk said:

What distribution and version of Linux did you use?

Looks like he is using Fedora Linux 39.

Hi Ki,

Sorry for my blindness, it was written above that Fedora was used.

In my experiments I was just trying to hit proper version of ubuntu,
I can use whatever works. I have empty board with clean SSD, so I can install any version. I will try Fedora 39 as you pointed out, but I prefer debian/ubuntu/xubuntu. Do you have any success with these 3 distribution, if yes please let me know the version I should use.

According to problem in 16.04, there was some message about 'undefined [...] and DS' - I cannot tell exact text.
It was not hung, just error message appeared. I found some complain in syslog and it was pointing that system glibc is too old (if I remember properly UniFlash required 2.25 but there was 2.22 in the system). General problem was that Uniflash cannot detect and probably communicate with XDS110.

I think it is not worth to analyse that version, 16.04 is very old.

It would have be nice if TI provided packages (e.g. .deb), so it would be easy to express dependencies. Unfortunatelly there are different packages systems depending on distribution. 

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

I will try Fedora 39 as you pointed out

I would not try Fedora as it is not officially supported. Please try Ubuntu 20 or 22. Let us continue discussion on your other thread.

Hi Ki,

I can understand that my system configuration can only get limited support. Usually, Fedora is ahead with package and kernel versions, so if issues crop up because of that, they might happen later on Ubuntu, too.

Anyway, back to your question. The GUI is hung insofar as it accepts no user input. Hovering over links still underlines them and the progress bar beneath "LOADING DEVICE LIST" is still animated. But no amount of clicking triggers any actions.

Restarting the application does not resolve the issue, only waiting for a pretty long time, can be hours or days until it works again. This led me to believe it might be either a time-dependent issue or a server-side issue.

Thank you for coming back to me so quickly,

Nicolas

Hi Nicolas,

I was fighting with the same problem as you did. 

I observed that only initial page is so slow. When uniflash switches to the main application view (where are flash programming, memory readout etc.) it works faster.

I suspect that:

1) the gui app is written in nodes-webkit (it is a lot of javascript, html), so it is interpeted - if I am not wrong all sources are provided for this part.

2) there are some ineffective procedures at the begining that cause hang. They are responsible for autodetection of jtag programmer (it can be disabled) and loading the list of devices - maybe this if from server [?]. 

3) maybe animation of the list is the reason [?]

4) there may be some tests of the uniflash updates - you can disable them too.

If you are not very attached to gui please check command line tools. They are under the gui. I already tested them on Intel Atom330 1.6GHz 2GB RAM - and speed of work is fine. 

Regards,

Piotr Romaniuk

Nicolas J. said:

Restarting the application does not resolve the issue, only waiting for a pretty long time, can be hours or days until it works again. This led me to believe it might be either a time-dependent issue or a server-side issue.

I assume you are using the standalone UniFlash tool and not the online one. For the standalone tool, the server would also be running on your local PC. Next time this happens, I would image a PC restart would resolve the issue. 

Piotr Romaniuk said:

I observed that only initial page is so slow. When uniflash switches to the main application view (where are flash programming, memory readout etc.) it works faster.

Yes. The initial page has some other activities that can impact things. The auto-detect feature relies on a local TI Cloud Agent installation. However, I can see Nicolas has this disabled by setting the detection to Manual. The device list population would be driven by parsing the device xml files available in UniFlash. It can take a bit of time but should be relatively fast on a decent machine - especially on Linux. I've never had an issue with the device list causing UniFLash to hang.

Nicolas - if the issue is fairly reproducible, can you try enabling GUI logging and then try reproducing the issue?

https://software-dl.ti.com/ccs/esd/uniflash/docs/v8_5/uniflash_quick_start_guide.html

Please see the section "Defect Reporting and Logging"

Hi Ki,

Ki said:

The device list population would be driven by parsing the device xml files available in UniFlash. It can take a bit of time but should be relatively fast on a decent machine - especially on Linux. I've never had an issue with the device list causing UniFLash to hang.

I observed that following operations work very slow:

1. initial populating devices list
2. entering device name for filtering them or clicking on famyli link (e.g. c2000)
3. scrolling the list

Regards

Piotr Romaniuk

Ki said:

I assume you are using the standalone UniFlash tool and not the online one. For the standalone tool, the server would also be running on your local PC. Next time this happens, I would image a PC restart would resolve the issue. 

Yes, you're correct, I'm using the standalone tool. I'm observing the issue on a fresh boot just now, I am fairly certain that a reboot does not solve the issue at all, it actually causes it.

Ki said:

Nicolas - if the issue is fairly reproducible, can you try enabling GUI logging and then try reproducing the issue?

Sadly, the GUI logging can only be enabled after the fact as it's not persistent. When I do enable logging after starting the GUI and try to manipulate it, empty errors are periodically logged:

09:00:37:029 error - {}
09:00:37:038 error - {}
09:00:37:044 error - {}
09:00:37:045 error - {}
09:00:37:056 error - {}
09:00:37:058 error - {}
09:00:37:065 error - {}
09:00:37:065 error - {}
09:00:37:124 error - {}
09:00:37:127 error - {}
09:00:37:130 error - {}
09:00:37:131 error - {}
09:00:42:057 error - {}
09:00:42:101 error - {}
09:00:42:319 error - {}
09:00:42:334 error - {}
09:00:42:351 error - {}
09:00:42:354 error - {}
09:00:42:367 error - {}
09:00:43:136 error - {}
09:00:43:168 error - {}
09:00:43:169 error - {}
09:00:43:217 error - {}
09:00:43:486 error - {}
09:00:43:502 error - {}
09:00:43:504 error - {}
09:00:43:519 error - {}

Ki said:

I can see Nicolas has this disabled by setting the detection to Manual. The device list population would be driven by parsing the device xml files available in UniFlash. It can take a bit of time but should be relatively fast on a decent machine - especially on Linux. I've never had an issue with the device list causing UniFLash to hang.

This seems to be connected to the issue! I can click the "Detect" button and as soon as it detects my probe, the device list gets populated and I'm able to further use UniFlash (even when closing and reopening it) until I reboot again. This is the debug log when it was stuck and I clicked on "Detect":

09:13:58:964 error - {}
09:13:58:972 error - {}
09:13:58:979 error - {}
09:13:58:980 error - {}
09:13:58:989 error - {}
09:13:58:990 error - {}
09:13:58:997 error - {}
09:13:58:998 error - {}
09:13:59:068 error - {}
09:13:59:070 error - {}
09:13:59:073 error - {}
09:13:59:075 error - {}
09:14:14:136 error - {}
09:14:14:139 error - {}
09:14:14:141 error - {}
09:14:14:154 error - {}
09:14:14:156 error - {}
09:14:14:158 error - {}
09:14:14:161 error - {}
09:14:14:162 error - {}
09:14:14:167 error - {}
09:14:14:168 error - {}
09:14:14:171 error - {}
09:14:14:172 error - {}
09:14:14:173 error - {}
09:14:14:175 error - {}
09:14:14:176 error - {}
09:14:14:178 error - {}
09:14:14:179 error - {}
09:14:14:184 error - {}
09:14:14:185 error - {}
09:14:14:188 error - {}
09:14:16:805 error - {}
09:14:16:810 error - {}
09:14:16:814 error - {}
09:14:16:817 error - {}
09:14:18:566 error - {}
09:14:18:570 error - {}
09:14:18:573 error - {}
09:14:18:579 error - {}
09:14:18:585 error - {}
09:14:22:998 error - {}
09:14:23:001 error - {}
09:14:23:003 error - {}
09:14:23:016 error - {}
09:14:23:348 error - {}
09:14:23:355 error - {}
09:14:23:358 error - {}
09:14:23:361 error - {}
09:14:23:364 error - {}
09:14:23:366 error - {}
09:14:27:620 log - NWAgentAPI: dinfraConfigue resolved successfully.
09:14:28:087 error - {}
09:14:28:090 error - {}
09:14:28:121 error - {}
09:14:28:294 error - {}
09:14:34:524 error - {}
09:14:34:526 error - {}
09:14:34:534 error - {}
09:14:34:545 error - {}
09:14:34:551 error - {}
09:14:34:556 error - {}
09:14:34:561 error - {}
09:14:34:577 error - {}
09:14:34:584 error - {}
09:14:34:612 error - {}
09:14:36:379 error - {}
09:14:36:386 error - {}

I feel like the manual detection feature is rarely being tested because it is not the default and thus exhibits buggy behavior.

Piotr Romaniuk said:

I observed that following operations work very slow:

You are running on an Intel Atom 330 processor, correct? If so, I would image the performance to be slow.

Nicolas J. said:

Yes, you're correct, I'm using the standalone tool. I'm observing the issue on a fresh boot just now, I am fairly certain that a reboot does not solve the issue at all, it actually causes it.

This is interesting. I will see if the UniFlash experts have anything else to add.

Nicolas J. said:

I feel like the manual detection feature is rarely being tested because it is not the default and thus exhibits buggy behavior.

I use the "Manual" option all the time since I rather not have the auto-detect run every time and never had an issue. The only difference between Auto and Manual is that you need to press Detect to run the detection feature while Auto will have the detection feature automatically run after UniFlash starts up.

The device list should get populated when UniFlash has started up, regardless of whether the detection feature has run or not. 

Ki,

I suspect that there is some "bottle neck" - an operation that cause slow down, or technology selected as a base for Uniflash. Maybe two levels of interpretaion is the reason - javascript interpretes xml and script files?

I pointed out these observation because they are connected in my opinion. I am just curious what the Uniflash GUI is doing that it is so demanding. 

On Atom 330 I have only 2GB RAM, maybe memory allocation is the issue for these technologies and it uses virtual memory [?].

I run the Uniflash GUI also at my laptop (4 cores, i5). First page is significantly slower. 

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

I run the Uniflash GUI also at my laptop (4 cores, i5). First page is significantly slower. 

Yes, there is a lot of xml processing of all the device/module/connection xml files going on in the background to generate that list. It takes about a second or two for me, though I do have a modern machine with a lot of RAM. A 4 core i5 is pretty reasonable. How long does it take for you with this machine?

Hi Ki,

Windows 7 64bits, 8GB RAM, Intel i7 M620 2.67GHz 2 cores (4 threads).

Click on Uniflash Icon -> auto detected xds110 + device list populated = 11 sec.

Click on Uniflash Icon -> manual detection (so postponed here) + device list populated = 8 sec.

Uniflash window appeared -> device list populated = 5 sec.

There can be multiple reasons, for example:

1. using O(2) algortihms or worse,
2. lack of synchnization between processes - e.g. when polling used instead signaling,
3. using time delay instead of 'back' signalling,
4. sending data in small parts,
5. a lot of memory allocations.

I am not telling that this is the case but in my opinion it is suspicious that gui requires so much resources. 

I understand that the main idea behind Uniflash was universal tool for every system confiiguration. This is not the most regular scenario of usage. I think that developers use one specific cpu model and one or two jtag programers. The configuration is predetermined, so there is no reason to populate the list where the choise is known. I know that session can be saved and restored but loading it is possible after device list populating is finihed. If I am wrong please correct me. It would be nice to specify from arguments to UniFlash GUI what to start and skip list population.

Unfortunatelly I have no time now for in-depth analysis of UniFlash, although it is iteresting, I need to finish first another tasks.

Regards,

Piotr Romaniuk

Piotr Romaniuk said:

I understand that the main idea behind Uniflash was universal tool for every system confiiguration. This is not the most regular scenario of usage. I think that developers use one specific cpu model and one or two jtag programers. The configuration is predetermined, so there is no reason to populate the list where the choise is known. I know that session can be saved and restored but loading it is possible after device list populating is finihed. If I am wrong please correct me. It would be nice to specify from arguments to UniFlash GUI what to start and skip list population.

You are correct in all of this. The goal was to have one UNIversal FLASH tool for all supported TI devices. To simplify things, there is only one install package that installs everything. It is expected that once a connection and device is specified, you can save the session and simply reopen it in the future so no need to select anything again in the future. But if the GUI is locking up before the session can be loaded, that is an issue.

Please note that we are aware of several limitations regarding the current implementation of UNIFLASH. We already have plans to move on to a new interface/design in the near future that addresses many of these issues. 

Hi Ki,

thank you for information.
Can we contact off the forum? I would like to discuss one more think related to uniflash.

Regards,
Piotr Romaniuk

You can start a private E2E conversation with me.