J-Link ARM stops responding once in a while in production process (using J-Link ULTRA+)

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • J-Link ARM stops responding once in a while in production process (using J-Link ULTRA+)

    Hi,

    I have a problem flashing circuits in mass-production process, using J-Link ULTRA+, as i describe in this ticket:
    http://forum.segger.com/index.php?page=Thread&threadID=1569&



    This problem we have is getting worse - In stations (Windows7,XP 32bit) where we have parallel processes, it happens several times a day.
    (Same PC, 2 different circuits, separate J-Link ULTRA+ to each circuit, separate executions - flashing happens +/- simultaneously)


    I'll describe here the problem again + more details =>


    I use CMD for the flashing process:
    "<JFlashARM.exe path>" -openprj"<project file path>" -open"<datafile path>",0 -auto -exit


    What happens is that once in a while - right after sending the line above - the GUI (J-Link ARM V4.74a) opens, and immediately stops responding.
    The only way out, is to disconnecting USB cable from J-Link ULTRA+ (killing the process from task manager doesn't help).
    We experienced this phenomena so far with two different chips: EFM32G210F128 & EFM32TG210F32.
    Could the chip type cause this problem?

    During our attempts to figure out the problem - we have found a message, that the application could not access some 'lock file' (it happened when one application was running, and the other one stuck).



    Are there any restriction for the application in parallel use?
    Do you have another application for flashing?
    Is there any other way to flash chips from CMD?
    Could it be that the instability appears because we use the CMD?
    May be it has something to do with the timing? I power up the unit, connect flasher, wait 100 msec, and then try to flash.
    Is it possible to flash the circuits without the application? May be if we write our own driver in Python for example?


    I would REALLY appreciate your help on this
    :)
    , this issue causes us a lot of problems
    :wacko:
    .


    Thanks in advance,
    Alex





  • Hi Alex,

    As you can see in the last thread, there were absolutely *no* issues reproducible here and we already invested some time in this...
    Without being able to reproduce, there is nothing we can fix (see other thread also)...
    What we need is a *reliable* way of reproducing this problem.

    One thing you could try:
    Having a copy of J-Flash in another folder (JFlash.exe + JLinkARM.dll)
    so that each instance of J-Flash has its own *.ini file etc. where the settings from the last session (recently opened project etc.) are stored

    Does this change anything?

    PS: Why do you open another thread for this if it is still the same problem with the same setup (except that you see the behavior with slightly modified setups too)?...


    Best regards
    Alex
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Alex,

    Thank for the advice, I'll try that.

    Sorry I've opened a new thread - it's just that I didn't get any reply for couple of days, so I thought it was counted as a resolved case from your side...

    Best regards
    Alex