• State Resolved
  • Locked Locked
  • Replies 19 replies
  • Subscribers 33 subscribers
  • Views 2259 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.

DK-TM4C123G: Requesting Mouser RMA verification

Jonathan Strang
Prodigy 60 points

Part Number: DK-TM4C123G

TI E2E Community,

I am seeking verification of a possible manufacturer's defect to allow for the acceptance of a Mouser RMA request. The following details the problem:

At the point of failure the device was connected to a computer via the IDCI USB connector and was recently programmed. Said program was actively running with no extra hardware attached to the device. During the program's operation, the device power indicator LED shut off and the device was no longer operational -- I suspect that the power regulator on the device may have failed. There was no physical interaction with the device for 30 seconds before failure, which leads me to believe that the board may have had a defect. Moreover, none of the typical odors due to component failure were evident on failure.

I connected to the board to another computer to test whether it was my computer that had the issue and found that the device debug communications port can be seen and correctly identified from the Windows device manager as "TI Stellaris (COMxx)" but the device still does not receive power to the rest of the circuit.

I did not attempt probing the device to test which exactly which component has failed nor have I inspected the manufacturer solder joints.

The program loaded onto the board that failed was later tested on another board and the program was found to be functional.

The program utilized interrupt-driven UART communications via the IDCI port (UART0),  interrupt-driven button press identification (ALL_BUTTONS), and an interrupt-driven comparator implementation (COMP0). The hardware necessary to test or utilize the comparator was not connected at the point of failure.

If you need any more information, I would be happy to provide it.

Thank you for your time,
Jonathan Strang

  • 0
    Genius 3850 points
    "which leads me to believe"

    you probably want to be more rigorous than that.
  • 0 in reply to Danny F
    Prodigy 60 points
    I could use more detail on where exactly you suggest "more rigor". The following lines are likely relevant to this comment:

    "Said program was actively running with no extra hardware attached to the device. ...There was no physical interaction with the device for 30 seconds before failure, which leads me to believe that the board may have had a defect."
    For this portion of the description, it seems very unusual for a product to fail on its own without physical interaction or externally connected hardware unless there was a defect or a critical design flaw.

    "I did not attempt probing the device to test which exactly which component has failed nor have I inspected the manufacturer solder joints."
    For this portion of the description, without testing and inspecting the board, I can only believe that there is a defect.

    "The program loaded onto the board that failed was later tested on another board and the program was found to be functional."
    For this portion of the description, the board the code was tested on is the same model as the board in question. In other words, both boards were the same part number: DK-TM4C123G. Moreover, this should address the question of whether the software could have contributed to the failure of the device.

    If you need any more information, I would be happy to provide it.
  • 0 in reply to Jonathan Strang
    Genius 3850 points
    " I can only believe that there is a defect. "

    don't believe it. prove it.
  • 0 in reply to Danny F
    Prodigy 60 points

    Per the 2018 EVM agreement (STANDARD TERMS FOR EVALUATION MODULES -2018):

    "the nonconformity was caused by neglect, misuse or mistreatment by an entity other than TI, including improper installation or testing"

    If you would like me to test it, please, from your TI official email, send me the approval, procedures, and required proof of work for testing, such that the referenced literature is not violated.

  • 0 in reply to Jonathan Strang
    TI__Guru*** 135355 points
    Hello Jonathan,

    Sorry for your issues. For the record, Danny F is a community member of the E2E community, not an official TI employee. TI Employee's are marked as such to the right of our names. Anyone posting with a 'Community Member' tag is not part of TI.

    Now then, with that cleared up, I would like to understand what you would need from TI for a Mouser RMA. Are they requesting some information from TI to process it?

    We don't really handle RMA's on the E2E forums, we debug technical issues, not handle EVM returns etc. - but if you need help from the TI side with a return through Mouser, I will provide you correct resources so long as I understand what exactly it is Mouser is wanting from you/us.
  • 0 in reply to Ralph Jacobi
    Prodigy 60 points
    Hi Ralph,

    Thank you for clearing the confusion up.

    Mouser provided the following quote upon RMA request:

    "For all defective development tools:The customer must first contact TI via
    E2E forum at http://e2e.ti.com/ to verify the failure. If the TI tech determines the part could be defective, please have the customer provide communication string to validate TI's approval to return/replace the kit. Once the string has been verified, then have the customer return the kit to Mouser Corporate office and send the customer a
    replacement, if they want one."

    If you'd like, I can provide the original communication thread to you.


    Respectfully,

    Jonathan Strang
  • 0 in reply to Jonathan Strang
    TI__Guru*** 135355 points
    Hello Jonathan,

    Thank you for that information. This is the first time I've seen such communication from Mouser for a TI EVM. I will look into what should be done next first thing tomorrow morning and provide guidance on the correct steps to move forward.
  • 0 in reply to Ralph Jacobi
    TI__Guru*** 135355 points
    Hello Jonathan,

    One thing to clarify from my end, you mentioned you can see the Stellaris Debug port in the Device Manager still right? When you try and debug in CCS, does it not recognize a valid device for programming? Also just in case it's needed so I can try and keep this streamlined, a picture of the EVM in which all jumpers can be seen would be good as well.
  • 0
    Guru 117855 points

    Jonathan Strang said:
    ...the device debug communications port can be seen and correctly identified from the Windows device manager as "TI Stellaris (COMxx)" but the device still does not receive power to the rest of the circuit.

    It is suspected that,  "for the device debug port to be seen" - the MCU serving as ICDI - must be powered.       And that power would seem "odd" to be uniquely routed to the ICDI MCU - alone - don't you agree?     I'd resolve that (apparent) conflict - prior to moving forward.

    Firm/I have noted,  "Two major issues which may harm the board's 3V3 Regulator:"

    • Drawing excessive current - most always due to,  "Add-on" Accessories
    • Introducing 3V3 directly (via the board's pin header - thus bypassing the 3V3 regulator - (if the DK board's power adhere's to the LPad's - the 3V3 screened markings are "Output intended" - Not input.)

    The disty enforcing this "extraordinary demand"  (note that even the vendor here is, "Caught off-guard") should be notified of your, "Broadcast of their policy."     Gently asking for a disty supervisor - especially if you/your firm/school have (some) buying "history" - should resolve this quickly...  (In over 10 years - here - maybe "once" -  was a similar request noted.)

    To prevent recurrence - I'd insure that ESD precautions are at all times, "Up/Running."       Firm/I have purchased several hundred LPads - never have we experienced such issue...

  • 0 in reply to Jonathan Strang
    Genius 3850 points

    "from your TI official email"

    as they often say, when you ass-u-me, you make an ass out of you and me - though mostly you, :)

    I was simply pointing out that based on your description of the issues and your actions, you cannot rule out other possibilities for failure. in a self-help world, that makes it difficult for others (TI or mouser) to conclusively say that the part you are trying to return is defective.

    you have to help them help you. and all we are trying to do here is to help you help them help you. 

    that's not a great situation to be in.

  • 0 in reply to Ralph Jacobi
    Prodigy 60 points

    Good morning Ralph,

    I have provided the images requested with the debug output for IAR provided instead of the debug output for CCS. I provided the picture with IAR as that is the environment that I am required to use. If preferable, I can recapture these images with CCS.

    The following image is a close-up of the DK-TM4C123G Plugged in to a computer:

    The following image shows the Windows Device Manager window, the IAR flash attempt output, and the DK-TM4C123G board: 

    Respectfully,

    Jonathan Strang

  • 0 in reply to Jonathan Strang
    TI__Guru*** 135355 points

    Hello Jonathan,

    From what I have gathered, TI handles return processes for boards shipped through our TI.com eStore. Not for other distributors. That Mouser is requesting TI to look into this has not come up before.

    I would ask you to do one more test with the DK board. Use our LMFlash Programmer software and try to do a Debug Port Unlock for your board. If it doesn't succeed in recovering your board, then go ahead and push them to finish the RMA. We aren't going to spend more engineering time on our end just to meet their own RMA requirements. Show them this post (and your proof of trying the LMFlash Programmer step) if needed.

    Download for LMFlash Programmer: http://www.ti.com/tool/LMFlashProgrammer

  • 0 in reply to Ralph Jacobi
    Prodigy 15 points

    I will private message you

  • 0 in reply to Amanda Dones
    TI__Guru*** 135355 points
    Hello Amanda,

    I have sent you an E2E friend request - we should discuss this topic further off the public forum for the moment.
  • 0 in reply to Jonathan Strang
    TI__Guru*** 135355 points
    Hello Jonathan,

    I spoke privately with Amanda RE: the RMA process, can you confirm if you've tried the Debug Port Unlock process with the LMFlash Programmer?

    Details for the process can be found here if you are unclear on how to do this: e2e.ti.com/.../310876

    Please report back if this is successful for you or not so we can move forward with the next steps.
  • 0 in reply to Ralph Jacobi
    Prodigy 60 points

    Hello Ralph,

    I did try the Debug Port Unlock process with the provided copy of the LMFlash Programmer as included with the DK. The program had reported that the procedure was successfully completed but there was no perceivable change in the DK's state of usability.

    Unfortunately, I am no longer in possession of the DK in question as Mouser decided to proceed with the RMA exchange.

  • 0 in reply to Jonathan Strang
    Guru 117855 points

    Should it not be noted - that this (particular) board is, "No longer to be stocked - by either Mouser or Digikey ... AND has been declared "Obsolete" ... by this Vendor!" 
    The expected "RMA exchange" may produce the, "Last Mohican" - and should (similar) issues befall  "that LAST & ONLY board" - what then?

    It is believed that Ralph & (other) vendor agents have directed client-users towards the (far lower cost) "EK-TM4C123GXL" as it continues to enjoy (both)  good availability and (continued) production.    Such notice - (below) - appeared here w/in the past week - receiving commentary from vendor agents:  Ralph & Charles.     (in chronological order...)

    https://e2e.ti.com/support/microcontrollers/tiva_arm/f/908/t/678337

  • 0
    Genius 3850 points
    It sounds like someone is more I retested in getting a damaged board exchanged than to figure out what might have caused the damage.
  • 0 in reply to Danny F
    Guru 117855 points

    Danny F said:
    It sounds like someone is more I retested in getting a damaged board exchanged

    Speaking of such,  "Re-Testing"  ...  years back - sailing out of Marina del Rey (Los Angeles) - I managed to "Run Aground" in the shallows of (neighboring) Long Beach harbor.     Coast Guard arrived to our rescue - and I was (shortly later) required to undertake, "Nautical Re-Testing!"    

    "Interested" may have (instead) - been intented.