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.

TM4C123GE6PZ: GPIO #09 errata workaround?

Part Number: TM4C123GE6PZ
We are seeing the errata GPIO #09 for the TM4C123GE6PZ IO pin latches to 1 volt.
Can only get out of it by sending a L-H pulse per errata workaround. That does work.
Question: When the GPIO is configured as an output, is it possible to use the
GPIORIS register (raw interrupt status) to monitor the output voltage (1V recognized as low),
to then trigger firmware sending the L-H pulse to get it out of that error state?
(We are driving it as a H output, but then can enter error state of 1V).
Would be nice to be able to monitor it, versus sending L-H pulses every now and then.
Thanks
  • Hi,

      Can you please confirm which errata you are referring to? There is no GPIO#09 for TM4C123. If you are referring to GPIO#10 then please see the workaround as to limit the slew rate on the IO so that the fastest rise and fall time is greater than 2 ns. Use an RC filter or series ferrite to limit the rise and fall times for at least the affected device pins. 

      I don't think you can be sure that it will always latch to 1V, not anything higher. If it latches to anything higher than Vil and that is 0.35 * VDD = 1.15V then you cannot detect the H-L transition. Since you can't guarantee it does not latch to higher voltage then it is a moot point for me to suggest software workaround. Otherwise, you could have routed the output pin back to another GPIO input pin with interrupt enable for H->L transition. When you detect an interrupt you can re-assert the output pin from L->H again. But how do you differentiate between an intentional change of state (H->L) on the output pin vs due to errata will be something to take care of too. Anyway, please use the workaround as documented in the errata document. 

  • Yes. My bad. Errata GPIO #10. Our proposed firmware knows of course whether we intend to drive it H or L so yes, that firmware would need to keep track of the intended state and observed state. We are trying to come up with something that doesn't require a significant hardware board rev if possible. The idea of monitoring the output via the GPIORIS came up as we looked at the GPIO conceptual diagram. I understand you are not recommending because you believe the failure mode could be anything, not just 1V. Understood. We have only seen 1.0V. You are recommending hardware board rev. For what its worth, we tend to see this if there is some GND power noise. Haven't seen it caused by high slew rate edge on the pin, as we only use it for GPIO output, but I understand that is your observed failure mode. Thanks.

  • Hi Charles/Gary,

    A customer of mine is a colleague of Gary and he wants to clarify something. See below response from him.

    "Charles says there is a software work around if we can guarantee the pin latches below 1.15V. I would like to hear what that work around is if possible. I understand it might not 100% fix the problem if the pin has a chance of latching at above 1.15 volt, but it would still be informative to understand the solution he would suggest if we could guarantee the pin latches below 1.15V. We would like to solve this without a major hardware configuration being required if possible."

    Regards,

    Art

  • Hi Art,

      The workaround is mentioned in my previous reply already. I wrote below in my previous reply.

    I don't think you can be sure that it will always latch to 1V, not anything higher. If it latches to anything higher than Vil and that is 0.35 * VDD = 1.15V then you cannot detect the H-L transition. Since you can't guarantee it does not latch to higher voltage then it is a moot point for me to suggest software workaround. Otherwise, you could have routed the output pin back to another GPIO input pin with interrupt enable for H->L transition. When you detect an interrupt you can re-assert the output pin from L->H again. But how do you differentiate between an intentional change of state (H->L) on the output pin vs due to errata will be something to take care of too. Anyway, please use the workaround as documented in the errata document. 

  • Hi Charles,

    Would this mean that there is no way to use the GPIORIS on a pin set to be an output to run an interrupt routine? Is interrupt functionality only available when the GPIO pin is set as an input? The conceptual diagram seems to suggest otherwise.

    Thanks,

    Art

  • Hi Art,

      Yes, you can enable interrupt while using output pin. It is just the explanation I gave when the pin latches to higher than Vil voltage.