• State Resolved
  • Locked Locked
  • Replies 14 replies
  • Subscribers 33 subscribers
  • Views 3198 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

EK-TM4C123GXL LM Flash Programmer Interface Speed

Andrew Coll
Prodigy 30 points

Other Parts Discussed in Thread: EK-TM4C123GXL

Short version:

Has anybody actually seen the LM Flash Programmer ICDI speed setting change the JTAG clock speed or am I misunderstanding something?

Long version:

Hi, we have been programming a custom target board with the EK-TM4C123GXL for several months with no issues.  However our launchpad board has started to have problems programming the target.  Erasing and blank checking never fail but programming fails with error 0x1 anywhere between 1% and 17%.  We have tried programming with multiple PC hosts and the problem follows the Launchpad board and is not specific to a PC installation.  

I wired up a new EX-TM4C123GXL board for JTAG output and it will program successfully each time with no errors, but the old Launchpad board will fail to program the same target board.  We removed the target power jumper at H24/H25 and even cut the traces on the Launchpad going from the JTAG header pads to the onboard target (U1) to eliminate the stub going to the other processor.

On our target board we are programming a TM4C123GH6PGEI with a full 256K bin file, erasing the entire part each time.  Our target does have JTAG pullups onboard and the JTAG wires are as short as we can make them.  We have a good ground connection and adequate bypass caps on the 3V3 power supply rail.  The target runs fine once programmed and we then use the serial port and the LM Flash Programmer tool for updates after initial programming with no issues.

After reading these forums I tried modifying the configuration of the LM Flash Programmer (Build 1613) to decrease the speed on the suspect Launchpad.

However no matter what setting I use for the ICDI speed or the clock source, a scope probe on the suspect Launchpad board shows the TCLK speed to be about 481 KHz.

When I probe the new Launchpad the TCLK speed is slightly lower at 461 KHz; this is the board that always programs successfully.

Has anybody verified the TCLK speed actually changes when you modify the ICDI speed or the clock source?  From the testing I've done I never get any value other than the 481 KHz on the suspect Launchpad or 461 KHz on the working Launchpad.

I confirmed the flash programmer is setting new values from the GUI because I can see it update the registry keys with the new value although it only seems to update them when you quit the LM Flash Programmer.  Upon restart you can see the new values have been loaded from the registry.  I started testing with the default values of JTAG port at 1000000 and "using selected crystal value" of 16 MHz.

With ICDI JTAG speed set to 1000000 it takes 14 seconds to program the board with TCLK about 461 KHz.

With ICDI JTAG speed set to   500000 it takes 14 seconds to program the board with TCLK about 461 KHz.

With ICDI JTAG speed set to   100000 it takes 14 seconds to program the board with TCLK about 461 KHz.

With ICDI JTAG speed set to   100000 and the clock source set to 4 MHz it still takes 14 seconds to program the board and TCLK remains 461 KHz.

Restarting LM Flash Programmer between each settings change to confirm the settings had changed.

Power cycling the target and the Launchpad between settings changes did not change the TCLK speed.

The only differences I can find between the two boards is the suspect board has a slightly faster 16 MHz crystal, it clocks in around 16.1 MHz sometimes according to the 100 MHz scope, I did not have access to a more precision scope.

Has anybody actually seen the ICDI speed setting change the JTAG clock speed or am I misunderstanding something?

Thanks.

Andy

  • 0
    TI__Guru**** 244440 points
    Hello Andy,

    I don;t think that on the ICDI the JTAG frequency will not change. It was for the FTDI boards that were released with the LM3 products EVM/LP's that the programmability takes affect.

    Regards
    Amit
  • 0
    Guru 47900 points

    Feel your pain - and it's likely that some of that pain should be directed towards the tech writer/team - pointing you/others in such direction.

    None of this is Mr. Ashara's fault - yet he gets to absorb the complaints...

    Might I suggest your migration to a (real) JTAG probe - specifically the J-Link - from Segger.   There is no doubt in my mind that this probe - and its related software - massively exceed the (performance) of your present "method."   (performance & method used out of "politeness")

    The number of JTAG issues - noted here - to my mind - far exceeds the "norm" as noted at other/similar ARM fora.   That said - my firm has long (and only) used the J-Link w/both LM3S & LX4F (and other ARM MCUs) - and we "never/ever" experience the issues - seemingly reported here - daily.

    Yes a proper tool may cost more initially - yet you've experienced the results (gained) from such cost-savings.  (i.e. you trade your time/effort/mental health for a "one-time savings.")  

    Segger site details - and a spectacular savings can be had via the "educational" model.   (you're advised against, "commercial use" - you can prove the tool's utility in this manner)   Firm/I receive no reward/incentive for this affirmation...

  • 0 in reply to Amit Ashara
    Prodigy 30 points
    Thanks for the quick reply, I suspected there was something I was missing. We are still very happy with the launchpad board since it got us going so quickly and we plan on sticking with the Tiva for the project. I just needed to close out the FA from the software team and assure the project manager this was an issue with my zero-dollar JTAG tool and not an issue with the board or the parts in general.

    I'm looking into borrowing/stealing under cover of night a couple of ARM Segger J-link adapters from a sister project who has carelessly left them in an abandoned cube although I need to look into licensing for the flash programming option. I think they only bought the base model and I'm going to need to do some test fixture development so I'll need to buck up for the more advanced J-link model when the time comes.
    Thanks again.
    Andy
  • 0 in reply to Andrew Coll
    TI__Guru**** 244440 points
    Hello Andrew,

    Thank you for the vote of confidence and a big thumbs up for Mr cb1-.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Guru 47900 points
    May an even (bigger) thumb be raised for Mr. Ashara - who handles ALL posts - not those "cherry picked" by mere forum interlopers...

    Not to "steal the thunder" from poster Andy - yet that, "under cover of night" pretty well describes firm's/my (beginning) Tool Acquisition Method... (I note: Judge didn't like me, barbed wire was not that sharp, wall wasn't that high - and the bars are "hard to notice" after the 2nd month...)
  • 0 in reply to cb1
    Expert 2355 points

    Hi Folks,

    As a user of some of the high quality JTAG units (ours happen to be ULINK2s), I too have seen intermittent problems develop when flashing development or production boards.  The culprit has always been a worn-out connector on the end of the JTAG units ribbon cable.  The tiny 10-pin 2x5 connector can "only" take 500 or so matings before intermittent problems develop.  This is certainly to be expected and is readily forgivable.

    By the way, we have moved the the Tag-Connect concept for all new designs.  It's nice to eliminate the rather high cost of the tiny 10-pin header.

    Hope this helps.

    Regards,

    Dave

  • 0 in reply to SourceTwo
    TI__Guru**** 244440 points
    Hello Dave

    Really, "500". That is very low. It is quite popular for the small form factor.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Prodigy 30 points

    If you want to MAXIMIZE unreliability then I suggest you use our de-facto standard of the Molex Picoblade for JTAG.

    I have no quarrel with Picoblade, it has served me well in several products in the past but it is not suitable for high mate and un-mate applications.  Somebody here a long time ago specified it for JTAG because it was small-ish and we were using it elsewhere and so it has stuck with us over the years because of internal process and inertia.

    You are absolutely right, connector issues are the first thing I check when they start reporting JTAG issues.  As soon as the software team starts having problems I chop off the Picoblade and crimp a new set of terminals on, they just wear out too quickly.  For production I'm using either regular test point pads or something like the Tag Connect.

    Andy

  • 0 in reply to Andrew Coll
    TI__Guru**** 244440 points
    Hello Andy

    Yes, Tag Connect is better. I believe the LP's are all using Tag Connect.

    Regards
    Amit
  • 0 in reply to Amit Ashara
    Expert 2355 points
    Hi Amit,

    Thank you for all your good work on this forum!

    Following is a link to the test report for the SamTec connector series we use to mate with the 10-pin 2x5 header (on our older designs). It looks as though the design intent, as reflected in the test report data, is actually 100 mating cycles..

    Link: suddendocs.samtec.com/.../147206_report_rev_2_qua.pdf

    Regards,

    Dave
  • 0 in reply to SourceTwo
    TI__Guru**** 244440 points
    Hello Dave,

    That kind of scares me and not use the 10 pin connector. Really appreciate your sending the link

    Regards
    Amit
  • 0 in reply to SourceTwo
    Guru 47900 points
    This reporter/firm - for at least past 4 years - have used that exact 10-pin, 2x5 (0.050") header/cable assembly - w/out issue!

    Now - the "Source's" report signals a, "Use Limitation" - yet cannot that be handled by allowing the short, 10 pin ribbon cable to remain connected - and by "breaking" the more robust, 20-pin connection which exits the J-Link or (lesser) U-Link?

    Surely we've "popped that 20 pin cable" beyond 500 times - and thru (luck or skill) we're (still) "On the Air!"
  • 0 in reply to cb1
    Expert 2355 points
    Hi CB1,

    Our approach is to replace the entire ribbon cable assembly as needed. We keep some of these in stock to reduce downtime: www.digikey.com/.../en

    The UNLINK2 has the requisite mini 2x5 connector inside, so replacement is as simple as removing/reinstalling one screw. If so inclined, snipping off the worn external connector and (carefully) replacing it it also an option.

    Regards,
    Dave
  • 0 in reply to SourceTwo
    Guru 47900 points

    Hi Dave,

    You've (too long) been quiet! Good to see you (again) making waves...

    If the 10 pin cable is to be chronically inserted & removed - then yes - regular replacement makes sense. And that's likely to occur NOT during product development - but instead during, "Multi-Board" programming.

    An alternative technique - which eliminates such cable - is a, "spring-loaded, bed-of-nails" fixture - which employs NO cable!   Firm/I "stole" this method from a "giant" - works superbly - and proves far faster & error free...

    For those interested - the "bed-of-nails" method makes NO SENSE during program development - usually is employed (only) when the program is finalized - and multiple boards are to be programmed.   This method SAVES the size/cost of the 10 pin mini header - replacing it w/pcb "pads only" which receive the spring-loaded, oxidation-piercing, test pins.