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.

TM4C1232H6PM: M4 GPIO physical model

Part Number: TM4C1232H6PM

Hi Champion 

My customer used TM4C1232 UART for communication, when they do the hardware signal test, sometimes it will cause the P16(U0RX), P17(U4RX) broken.  When test these two pins resistor according GND, it decrease to 200~600 Ω.  Normally these two pin should in tri-state when power off and the resistor is infinite.

This also cause the RX signal voltage level decrease to 1.96v.

And customer want to know M4 GPIO physical model, which help them to analysis why will happen this condition? Do someone have this ?

 

  • Eric Ma said:
    ...when they do the hardware signal test, sometimes it will cause the P16(U0RX), P17(U4RX) broken.

    As the "hardware signal test appears to "cause" damage - should not (some) details of that "hardware signal test" be provided.     (so that the test may be analyzed)

    Historically such UARTs were "level shifted" (to RS232) levels - and if those (RS232) signal levels are fed (directly) to the MCU's UART pins - damage (in time) is sure to result.

    Having monitored this & predecessor forum for >10 years - firm/I have "never noted" any such tendency for "UART pins" to suffer such failure when (properly) treated...

  • Eric Ma said:
    Normally these two pin should in tri-state when power off and the resistor is infinite.

    Also this is not true. There is a path through the protection circuitry to the power rail and back to common.  I wouldn't expect the resistance you are seeing but there is a path and the impedance is likely voltage dependent.

    Robert

  • Hi Robert
    I test the resistance when power off, and I compare with two device, the good one resistor is infinite, while the issue device 200~400 Ω。

    Eric
  • Hi cb1
    As the "hardware signal test appears to "cause" damage - should not (some) details of that "hardware signal test" be provided. (so that the test may be analyzed)
    Historically such UARTs were "level shifted" (to RS232) levels - and if those (RS232) signal levels are fed (directly) to the MCU's UART pins - damage (in time) is sure to result.
    Eric: Customer connect U0Rx with HVD3082. In the hardware signal test, they solder a wire in U0Rx, then use scope to capture waveform. I don't know whether it is ESD short when in the test.
  • Eric Ma said:
    Customer connect U0Rx with HVD3082. In the hardware signal test, they solder a wire in U0Rx, then use scope to capture waveform. I don't know whether it is ESD short when in the test.

    So there is both an injected signal and the signal from the transceiver?

    Also they are soldering directly to the micro?

    If so, this would seem to fall under the category of don't do that.

    Robert

  • Eric Ma said:
    In the hardware signal test, they solder a wire in U0Rx, then use scope to capture waveform.

    Would it not prove: "Safer, Faster, Easier" for the customer to "more conventionally connect" to the UART (via) a header - especially if the UART "speaks" to an "off-board" device.    (or - at least - to a pair of plated-thru-holes via "spring-loaded test pins" - driven by a "proper" UART source/receiver.

    This method of "measuring resistance" - if not done properly - may (in & of itself) DAMAGE the MCU!     (the protection circuitry w/in the MCU is sensitive to voltage - and when MCU is, "powered off" - elements of that "protection" are weakened or may be "non-existent" - neither good...)

  • Hi Robert

    So there is both an injected signal and the signal from the transceiver?

    Eric: Yes. now is the MCU RX pin abnormal, which is injected signal from transceiver.

    Also they are soldering directly to the micro?

    Eric: No, soldering to a resistor which connect with MCU RX.

  • Hi cb1
    Customer test condition is, using scope to check MCU UART RX signal condition, and found 4 devices(total 200pcs) have this abnormal condition(signal voltage level down to 1.96V). They found the signal is cause from MCU side by compare test. After this, they do the resistance measure of RX pin to confirm the pin is abnormal with correct one. So it should not the resistance test to damage MCU.
    Another question is, whether you have the model of IO protection circuitry ?
  • Eric Ma said:

    So there is both an injected signal and the signal from the transceiver?

    Eric: Yes. now is the MCU RX pin abnormal, which is injected signal from transceiver.

    Also they are soldering directly to the micro?

    Eric: No, soldering to a resistor which connect with MCU RX.

    OK, at least a pin to pin short is not likely.

    So I see the following immediate possibilities

    1. The injected signal overrides the transceiver, and everything tests fine w/o damage
    2. The injected signal overrides the transceiver, and damages or weakens the transceiver (If you are performing your resistance measurement with transceiver in circuit you cannot differentiate between a damaged micro and a damaged transceiver)
    3. The injected signal and the transceiver signal come to a mid-scale equilibrium and damage the micro's input.
    4. ESD damage occurs (possibly while soldering)

    Side note: You found 4 units failed in 200? You're soldering test wires on the boards as a production test? If so you're doing something wrong. Actually I'd question this even if it was just a lab test.

    Robert

  • Poster Robert, "Why not use the transceiver?"

    Almost identical to my earlier post - inject (proper) signals thru a board header - not a "tack solder" add on.

    It is (still) unclear if the "scope measure @ RX" is done BEFORE any issue is discovered.    The lack of "proper and/or common ground" may enable that scope measure to "play the villain."

    Robert's point, "the common connection between UART_RX & Transceiver" indeed yields, "TWO likely suspects" - yet (you appear) to cast, "All blame upon the MCU!     Why is that - how & when have you (properly) isolated the common "Xcvr-MCU_RX" connection?     And - have you performed a "similar/parallel" measurement upon the Xcvr's pin?

  • Hi Robert

    Thanks for your comment. The FA report shows RX pin short to GND. 

    "You found 4 units failed in 200? You're soldering test wires on the boards as a production test? If so you're doing something wrong. Actually I'd question this even if it was just a lab test."

    This is customer product performance test in pilot run, they will the the hardware signal using scope, like UART, USB, and so on.

    So you say solder wire are wrong, what suggest to customer if they want to test the hardware signals?

     

  • Hi cb1
    Thanks first.
    "Why not use the transceiver?" you mean test the signal using transceiver's pin, not directly test MCU RX pin, right? As previous post, there is a HVD3082 connected with MCU.

    I also think about the RX pin short fail casue by three possible:
    1. the scope measure ground problem cause overstress on MCU RX pin.
    2. it may the inject signal from transceiver that cause overstress.
    3. ESD when soldering.
    It is make sense?
  • Eric Ma said:

    This is customer product performance test in pilot run, they will the the hardware signal using scope, like UART, USB, and so on.

    So you say solder wire are wrong, what suggest to customer if they want to test the hardware signals?

    For testing use the transceiver you already have connected to the pins. You already got a connector for that and you test not only the micros I?O but also the transceiver and the connector.

    If you have failures to investigate or you are needing to verify the transceiver performance and you have neglected to provide test points then you can consider soldering test leads while being aware that you run some risk of damaging the board you are investigating. I've done this in the past, probably will do so in the future but I wouldn't do it for production testing.

    Robert

  • Eric Ma said:
    "Why not use the transceiver?" you mean test the signal using transceiver's pin, not directly test MCU RX pin, right? As previous post, there is a HVD3082 connected with MCU.

    Which you can use as both cb1 and I have  suggested.

    Eric Ma said:
    I also think about the RX pin short fail casue by three possible:
    1. the scope measure ground problem cause overstress on MCU RX pin.
    2. it may the inject signal from transceiver that cause overstress.
    3. ESD when soldering.

    1. The scope is unlikely to introduce an issue itself. It could if improperly grounded, although in that case other locations would also be susceptible. More likely is that since you have a 'scope probe attached to a flywire that cobbled together construct will either cause a short to something else on the board, or conduct ESD.
    2. If you are driving the line from both the transceiver (ie the transceiver is connected) then it is entirely possible that the signals will be forced to a stress point. I think I mentioned that earlier. I'll find and quote.
    3. ESD when soldering. Or ESD when applying the probe connection.

    Robert said:
    So I see the following immediate possibilities
    1. The injected signal overrides the transceiver, and everything tests fine w/o damage
    2. The injected signal overrides the transceiver, and damages or weakens the transceiver (If you are performing your resistance measurement with transceiver in circuit you cannot differentiate between a damaged micro and a damaged transceiver)
    3. The injected signal and the transceiver signal come to a mid-scale equilibrium and damage the micro's input.
    4. ESD damage occurs (possibly while soldering)

    I think you've eliminated possibility 2, at least for one device.

    Robert