• State
  • Locked Locked
  • Replies 19 replies
  • Subscribers 31 subscribers
  • Views 491 views
  • Users 0 members are here
Support feedback
Options
Options

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.

UNIFLASH: Linux desktop application sporadically stuck

Nicolas J.
Prodigy 20 points
Part Number: UNIFLASH

I often run into the issue that UniFlash is stuck on startup with the message "LOADING DEVICE LIST". No actions can be taken when this happens, clicking on existing sessions doesn't work. This issue only happens sporadically and it's very inconvenient that this completely blocks the GUI. A quick search did not turn up any usable logs pertaining to UniFlash that I could attach here.

UniFlash Version 8.6.0.4688 (Installed as user into my home directory)

OS: Fedora Linux 39

  • 0
    Expert 2830 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    Piotr Romaniuk said:
    What distribution and version of Linux did you use?

    Looks like he is using Fedora Linux 39.

  • 0 in reply to Ki
    Expert 2830 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    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.

  • 0 in reply to Ki
    Prodigy 20 points

    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

  • 0 in reply to Nicolas J.
    Expert 2830 points

    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

  • 0 in reply to Nicolas J.
    TI__Guru**** 450031 points
    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. 

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    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"

  • 0 in reply to Ki
    Expert 2830 points

    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

  • 0 in reply to Ki
    Prodigy 20 points
    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:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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 - {}
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    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":

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    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 - {}
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    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.

  • 0 in reply to Nicolas J.
    TI__Guru**** 450031 points
    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. 

  • 0 in reply to Ki
    Expert 2830 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    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?

  • 0 in reply to Ki
    Expert 2830 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points
    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. 

  • 0 in reply to Ki
    Expert 2830 points

    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

  • 0 in reply to Piotr Romaniuk
    TI__Guru**** 450031 points

    You can start a private E2E conversation with me.