• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 571 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TM4C1294KCPDT: OTG port cable plugged into self powered device, MCU powered off.

Genatco
Guru 54057 points
Part Number: TM4C1294KCPDT
Other Parts Discussed in Thread: EK-TM4C1294XL

Should not the MCU dedicated pin PB1 +5v tolerant pin be capable to stop excessive current flow by design?

What customer would ever think they must first power off the OTG self powered device so VBS pin don't get stressed. Is not the point of OTG standard being hot pluggable, what customer is ever going to not plug the (user friendly) self powered device into a active Host system and leave the device powered on while removing power from the MCU OTG host. Tivaware USB Bulk device client plugs into a Windows host computer and VBUS pin is always providing +5v to MCU pin (PB1) even when the MCU is sometimes powered off. Unless the customer decides to unplug USB cables every time they re-power the MCU, an insane idea to begin with as no customer is ever going to do that. This issue also effects developers using the USB0 peripheral VBUS pin PB1 for powering an OTG device via EX-TM4C1294-XL launch pads for sending data into a host Windows system. The OTG port design is not (fully) fault tolerant as it is being used in USB0 device software development to transport large sums of data into a Windows host computer. 

That said have not the experts of MCU companies stress tested USB peripheral pins under several different scenario? The one they seem to have missed is users are not going to concern themselves with how hot pluggable (self powered) devices must be powered in some particular order. Who would ever think IEEE proven OTG standard should have any such limitation when it comes to how basic users do things. So the USB peripheral pins must be fault tolerant on all levels of the OTG standard not just one or even a few, all levels! 

Has not a Schottky series diode been manufactured into PB1 to stop current flow out the MCU pin PB1 when the MCU has no LDO or rail power? Perhaps some kind of series resistor may also be required such as the TM4C123g often has with ICDI ports, might that defeat IEEE OTG standard protocol for VBUS signaling? Otherwise it would seem a photonic VBUS coupling should have been developed into the silicon or IEEE standard needs to be revisited.

MCU pin PB1 gets stressed under (repeated) condition where the MCU is powered off for several hours prior to the self powered device removing power from VBUS.

  • 0
    Guru 117850 points

    BP101 said:
    Who would ever think IEEE proven OTG standard

    BP101 said:
    might that defeat IEEE OTG standard protocol

    BP101 said:
    the silicon or IEEE standard

    Is not the (actual)  governing standard for USB the  "USB-IF" - not the IEEE?    (www.usb.org  introduces this page - revealing ACTUAL governance...)

  • 0 in reply to cb1_mobile
    Guru 54057 points

    That might explain the poor pin/port design ? and all global companies falling victim, not properly testing MCU pins for typical power stresses from OTG devices. Yet IEEE had past managed external wire connections typical peripheral ports (COM, Parallel etc..) of all computers. USB compliant by standards that don't protect the MCU from OTG self powered devices, has failed to do any good!

    Third MCU to stress +5v tolerant pin PB1, USB cable only plugged into MSi mother board USB peripheral port handler. It's not like we invented this concept, it has become an industry norm to use USB to transfer large amounts of data from a target into Windows host computer. 

    The main difference is the EK-TM4C1294XL is more often being powered from ICDI port 3v3 LDO regulator not OTG VBUS pin JP1, though it can be. MCU pin PB1 is not being (directly) subjected to typical stresses of a self powered OTG device if ICDI is still powering the MCU, unless JP2 or JP3 has been removed for (rare) testing. 

    What is any work around, simple inline (components) to stop +5v tolerant PB1 from being stressed when the self powered OTG device is left powered as the MCU power is removed?

  • 0 in reply to Genatco
    Guru 117850 points

    Would not - directing your issues/concerns to the (actual) USB governing organization (Not IEEE) - prove useful?      (there's no indication that you've done so...)

    Have you not experienced this problem - uniquely - or at least, "w/ Far more severity" - during your "Test/Verification" of your (just completed) custom pcb?      (such should be noted - should it not?)

    Have you made diligent use of this forum's Search feature - perhaps noting the, "Frequency of such, "Overlapping, PB1 destructive occurrences" suffered by  others - here?"

    Minus your presentation of, "Others here - suffering identically - and in large numbers" - does your case prove  (sufficiently) compelling?

    The (proper) design of such a "custom pcb" - along w/the necessity to practice (proper) ESD safeguards (throughout the entire build process) - and the employment of (proper) board assembly techniques (& equipment) - cannot be ruled out - as more reasonable "cause" of your (continuing) issues...

  • 0
    TI__Guru*** 128095 points

    Hello BP101,

    I believe we have a misunderstanding of what TI promises, what TI suggests, and what *you*, as the system designer, are responsible for.

    Our datasheet offers the following information about the USB peripheral which you can hold to us to:

    • Complies with USB-IF (Implementer's Forum) certification standards
    • VBUS droop detection and interrupt

    Note that no where does it promise VBUS pin should be 'capable to stop excessive current flow by design'.

    Furthermore, we have a full section about what ESD promises we make: 27.14.1 Types of I/O Pins and ESD Protection regarding current flows and over voltage situations, so you can understand the limits of what we can do with an MCU priced at the level it is as far as I/O pin protection and can then add additional protections as needed for your system.

    That outlines the extent of our promises to you about device operation.

    Now then, we do try and do some leg work for all our customers, and offer reference designs. These are our recommendations for systems under normal operating conditions. We do some basic testing to ensure the design operates as we anticipate, and release these designs to use a reference for each customers system. However, the designs are not meant to be 'ultimate solutions' which need no modifications, changes, etc. They are reference designs which you can refer to for beginning your system design. If you find your system subjects the device to conditions that are beyond what we tested on our reference design, then you need to account for that on your end. Our MCU's are used across 100's of industries/end applications, we cannot possibly account for every single one of them.

    That is where *you* come into the picture. We can arm you with data about how the MCU should behave, and recommended design concerns you should consider through reference designs and documentation which demonstrates proper layout, suggests some of MANY possible external components etc. - but then you need to determine if your system will require further steps to safeguard it.

    Also keep in mind with the LaunchPad... we are offering a development kit that usually would be priced upwards of $100+ for just $20. On top of that, we have it crammed to the brim with all sorts of useful evaluation elements. Did you ever consider that the reason we didn't release a full TI reference design for the LaunchPad is because while it is perfectly functional for evaluation of the device, that it isn't an end-all be-all point to reference? Where have we ever suggested you should design entire your system based on the LaunchPad? I am sorry that your USB hub has seemed to uncover that the OTG port of the LaunchPad can expose the MCU to an excessive current draw, but you still are the only user to come to us with this complaint so it's pretty clear this is a niche use case of our LaunchPad with a specific powered USB hub and not a recurring theme affecting a broad set of our users. Therefore ultimately, all I can suggest is that you'd be best of refraining from using that USB hub with the LaunchPads.
    Lastly, now that you have concerns about how to protect the USB port, you should look into what else you can do in addition to our recommended design guidelines to further enhance your system, as many other customers did - which I feel safe to say due to a complete lack of complaints about our MCU's USB hardware being flawed as you are highlighting.
  • 0 in reply to Ralph Jacobi
    Guru 54057 points

    I think TI has used the words 5 volt tolerant incorrectly relating to VBUS pin as the MCU input to PB1 is in no way any such thing but highly volatile.

    Ralph Jacobi said:
    Where have we ever suggested you should design entire your system based on the LaunchPad? I am sorry that your USB hub has seemed to uncover that the OTG port of the LaunchPad can expose the MCU to an excessive current draw, but you still are the only user to come to us with this complaint so it's pretty clear this is a niche use case of our LaunchPad with a specific powered USB hub and not a recurring theme affecting a broad set of our users.

    The concept of Launch pads are to rapidly accelerate products into the market place (without) making major changes in circuit designs to existing interfaces on the launch pad, thereby reducing designer development time. How has that concept been lost is more the question needing to be answered and how can that train wreck be rectified by introducing (proper) MCU pins or circuits around them that are truly 5v tolerant under most all external powered connections. We are not the only ones to see this issue as it masks into VDD excessive current draw which elevate MCU temperature and effect other peripherals in odd ways. The problem is those who have been affected by this failure of PB1 pin are unaware it even occurred and why would anyone ever think plugging the EK-TM4C1294XL OTG port into a computers USB port is anything but safe?

    Seemingly the failure of PB1 is occurring not by plugging USB0 into a hub as you mention, rather simply being connected to a computers USB port and depowering the target launch pad somehow stresses PB1. Why has the customer been subjected to this failure of OTG to MCU pin PB1 a supposedly 5 volt tolerant pin is more concerning. There is some kind of (destructive) current flow occurring on VBUS pin into MCU pin that should not be occurring under any conditions. The work around to put scotch tape on the USB cable VBUS pin is not the answer here. The USB DP/DM remain fully functional though OTG signaling via PB1 is no longer possible when failure of 5v tolerant pin occurs. This time PB1 pin was protected only via OnSemi  ESD9C3.3S-D device and it is perfectly functional after PB1 pin was stressed not by ESD rather by current flow through the 5 volt tolerant pin PB1. Our understanding of what claiming 5 volt tolerant by definition obviously differs from that of TI engineers as the MCU pin PB1 is (NOT) 5 volt tolerant under most (typical) conditions. TM4C129x MUC pin PB1 is 5 volt (dependent), and not 5 volt tolerant as it can be destroyed by 5 volts!

    That said it would seem that somewhere the TI marketing ball has been dropped by product development! TI is not the only company producing such development systems and product engineers are simply copying each others designs without back tracking how those designs might impact customers developing systems from their products.

  • 0 in reply to Genatco
    Guru 54057 points
    BTW: We followed System Design Guidelines TM4C129 Family of Tiva C Microcontrollers (SPMA056–October 2013) for USB port layout, with OTG support being possible. Also added PCB perimeter frame ground was tied to computers frame ground is (40 ohms common to AC ground) and Earth ground bonded in electrical panel.

    PB1 was stressed by depowering MCU while PB1 was supplied 5v via (computers) USB port. DMM now measures 470 ohms relative to ground @PB1 versus 6.8megoms prior to stress and now measures 0.465v diode drop to ground, even flipping DMM probes. MCU temperature is elevated by 4*C and VDD pins are sourcing excessive current from 3v3 LDO regulator. Yet the MCU seems to run ok can do Flash writes after forcing VBUS/ID pins high in software adding tape over VBUS pin of USB cable.
  • 0 in reply to Genatco
    TI__Guru*** 128095 points

    Hello BP101,

    5V tolerant refers to voltage, not current... there's a big difference isn't there? Our design guidelines mention various steps regarding how to limit ESD events by reducing the current such as using series resistors, or ESD suppressors.

    BP101 said:
    The concept of Launch pads are to rapidly accelerate products into the market place (without) making major changes in circuit designs to existing interfaces on the launch pad, thereby reducing designer development time.

    No... and that concept isn't lost. You may have just misinterpreted the purpose of LaunchPad's.

    LaunchPad's are to enable rapid prototyping without needing to worry about getting debuggers and other tools while having access to fundamental MCU peripherals along with being compatible with our BoosterPack ecosystem to expand the evaluation options to a wide breadth of TI products.

    LaunchPad's are not reference designs meant to be cut and paste into your system. That has always been the case.

    Furthermore, even with our reference designs, design guidelines etc. - we are still not ultimately responsible for ensuring your system is flawless, that responsibility is on you. Now if you need advise on what to do, that is where we can come in and assist with what knowledge we have on such topics. But we aren't all knowing entities that can predict every situation and while we can help solve identified problems, we are not liable if you didn't catch those problems on your end even if you started from our reference design. Such is stated quite clearly here: http://www.ti.com/lit/ml/sszz031f/sszz031f.pdf

    Now then, I'll go ahead and move us forward to the problem at hand as that is the only thing I can help with, as you are right, scotch tape on the USB isn't a solution.

    First let's get to a simple agreement I alluded to at the top of my posting... 5V tolerant is 5 VOLT tolerant - and that doesn't speak for CURRENT. Can we agree on that at least? Obviously there is a problem with the current overdraw. We need to solve that. But that doesn't invalidate our 5V tolerant statement because all that means is that if you apply 5V to the pin for extended periods of time, it will be fine which is unique to VBUS on the TM4C device. That doesn't mean a fast transient with high *current* spike can't affect it.

    Regarding system design guidelines, which specific mode are you going to be using for OTG? Host? Device? Do you need to support SRP and HNP protcols?

    Can you share the relevant schematic snippet for the USB OTG setup on your custom board which has had issues? I want to see the external component selections made for protecting the device.