• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 31 subscribers
  • Views 1019 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.

TM4C1294NCPDT: Programming issue on some parts TM4C1294NCPDT

Dorel Dumencu
Prodigy 180 points
Part Number: TM4C1294NCPDT
Other Parts Discussed in Thread: UNIFLASH

We bought 6 parts from Digi-Key for the R&D project and I was able to program 3 of 6.

Later I erased the flash of one working board with LM Flash programmer, cycle the power to the board and I'm not able to program this board anymore. I followed e2e reported issues, I tried to unlock the part; still not able to program the part. Them I captured the communication over the JTAG and all the data packets looks great, similar to those on an working programming microcontrollers. On this trouble parts, I see just on packet of communication over JTAG and than the uploader reported error : "ERROR, unable to initiate the target-0". we used LM flash programmer, CCS or Uniflash, with same results. The content of this first data packet look identical to the first packet of other working micros. At least I  checks couple for data, against the working micros and they look identical.

Please let us know if this is a trouble part or is anything else we can do to fix this issue. 

Don't get me wrong, the working microcontrollers, work as great as the specs, the only issue is with programming on some batches.

I am using this part for more than 2 years on other projects and I never encounter issues like this before.

Thanks,

Dorel

  • 0
    Guru 117855 points

    With so "small" a part sampling - and not knowing (at all) of the design & execution of your (assumed) pcbs - it is very difficult to, "Blame the vendor!"

    ESD comes quickly to mind - w/so small quantity - has your team - at each/every level of handling - (really) enforced "Proper ESD Procedures?" Are your boards correct - how was that determined - there are (many) potential causes (beyond the MCU) which may create/contribute to your issue...

  • 0 in reply to cb1_mobile
    Prodigy 180 points
    We are designing boards and use the same board assembly for very long time. In PCB design we are extremely professional, the boards are working from rev1 and pass the UL certification if we go through. It's not a PCB or design. I'm using this part in older design with no problems.
    When we do design and manufacturer first batch, common sense is to assembly limited number of board. Correct ?! The questions are:
    - is JTAG damaged? The signal captured over JTAG shows great signal and the part is responding. I assume the JTAG communication is working.
    - how about the board which was working and lately after erasing the flash , not working anymore.
    - I'm here for answers , not requesting parts replacements
    - do you assume we need to replace the parts? We never had ESD issues in the past. I don't believe this was an ESD issue.
    - is anything else we can check or do to make it to work?
    - is external clock mandatory for programming the part? I assume not, because we enable it later in execution


    Thanks,
    Dorel
  • 0 in reply to Dorel Dumencu
    TI__Guru 72500 points

    Most issues reported like this end up being board design or JTAG scan controller issues.  You are correct that the external crystal is not required for device programming as the device initially runs off of PIOSC.

    The lack of an RBIAS resistor causes JTAG issues sometimes. See erratum ETH#03 which I copied below:

  • 0 in reply to Dorel Dumencu
    Guru 117855 points

    Dorel Dumencu said:
    use the same board assembly for very long time.

    followed then by:

    Dorel Dumencu said:
    When we do design and manufacturer first batch, common sense is to assemble limited number of board. Correct ?

    Is there not "conflict" between the top quote and the second?     Mentioned is "same board" and then "first batch" - that is "not" as clear as it could be - is it?

    ESD IS insidious - it is "unusual" to find "Full ESD Procedures" being enforced - when quantities are so small.    (unless yours is a "high functioning" lab - which the representation of "R&D" casts in question)     You "don't believe ESD was a cause - yet provide "no support" for such belief.    (ESD damage may occur (anywhere) in the unpacking/handling/programming/testing process!)

    Power Supplies, cables, placement of "boards to be programmed" upon a "safe surface" - all must be considered.     UL (and other) forms of "certification" stress product safety - thus are "unlikely" to "pass any judgement" upon "low level" JTAG signal/routing conditions.

    This JTAG issue "has" been long noted here - our firm - either thru luck (or some skill) or superior tools (J-Link and paid IAR IDE) has "escaped this issue."     Note too that every bench has "grounding wrist straps" and our use of "ESD approved handling methods" - while (bit) bothersome - (may) have saved us from your (and multiple others) unwanted fate...   

    I do "feel your pain" - and have "made the effort" to provide (reasonable) considerations and/or methods which (may) have enabled us to escape your misfortune...   And (just may) work for you - as well...

  • 0 in reply to cb1_mobile
    Prodigy 180 points
    Thanks for replying , if you think this might be an ESD I'll look into the manufacturing procedures, replace the damaged parts.
    The reason I raised this question is because we have another board issue with a MSP432 micro, quite similar. In that case I can program a number of boards using CCS7 or Uniflah but have the programming issue on the others. Fortunately if I use CCS 6.0 it does change the programming tool firmware and I'm able to program all the boards. This is very weird and it doesn't fall into the ESD matter right?
    I already talked to my board assembly house but with all atypical behaviors, very hard to solve. Any comment of MSP432, please? Any other suggestions?


    Thanks,
    Dorel
  • 0 in reply to Bob Crosby
    Prodigy 180 points
    great tip Bob; works Appreciate.

    Thanks,
    Dorel
  • 0 in reply to Dorel Dumencu
    Guru 117855 points

    Poster Dorel wrote: "We are designing boards and use the same board assembly for very long time."

    Yet - unexplained - your claim of "prior board experience" - which suggests that you (once) followed this (known) "R_Bias" requirement - and have (now) forgotten!

    As to MSP - we prefer ARM Cortex M0/M0+ for "lesser" demands.    (those devices - apparently - ruled too competitive to be carried here...)