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.

LM3S1918: LM3S191 problem

Part Number: LM3S1918

Hi team 

Good day

my customer need some help :

We are having excess current on Power up during testing at Hot +68C. It's occurring in about 5-10% of product. We seem to have narrowed it down to being related to the internal voltage regulator (LDO). Are you aware of what could be causing this issue?

Regards

Aosker

  • Hello Aosker,

    My first thought hearing this is that it could be related to the errata LM3GPIO#02: https://www.ti.com/lit/pdf/spmz860

    This E2E thread also raises the idea of glitches on I/O being the cause, though it was never pushed to resolution: https://e2e.ti.com/support/archive/stellaris_arm/f/471/t/106657

    What makes the customer think that the LDO is the reason here? Could they share more details about what testing they did and what they observed? Is the issue occurring only during power up or also after power up? It sounds like it is during only but want to confirm this.

    To the point of the glitches, can they see if any pins have a voltage applied to them before the power up sequence has completed?

    By the way I just want to mention with this initial post that these devices are quite old and our team is not deep experts with them, so while we will try and help to the best of our capability, there may be limits to what we can offer from a support standpoint.

  • We have looked at LM3SYSCTL#25 in the errata and made sure the capacitance is in the suggested range (nominal 1 uF). Various capacitance values did not change our failure mode.

    The specific failure occurs on about 5% of our systems and only at hot temperatures (45C-70C). For the units that have this failure mode, it is very repeatable at the specific temperature of failure. During this failure mode, excess current pulse on VDD33 of roughly 1A lasts for about 15 ms, and the unit does not function (probably due to current limit). On rare occasions (intermittently) the 1A pulse will drop quickly after about 12ms and the unit will recover and function. This recovery mode is only possible if we increase the power supply current limit to 1A, and even then only intermittently.

    We have probed the LDO voltage, and during the failure the LDO rise to 2.5V lags the VDD33 rise to 3.3V by roughly 15 ms. Normally LDO lags VDD33 by only about 2 ms.

    Any help is appreciated as to what may be causing this excess current pulse on power up.

    Meanwhile, we will look at your errata LM3GPIO#02 concerning glitches and the E2E thread.

    Thanks,

    Mike

  • Hello Michael,

    Thank you for the additional details here regarding the timing, failure rate, and temperature range.

    I am still not 100% clear if this is only an issue that occurs during power up or if it ever occurs after power up - can you confirm that it is only during power up?

    Right now it sounds very much related to LM3GPIO#02 as a key statement of that errata item is "As a result, a signal glitch may occur on GPIO pins before both the external VDD supply and internal LDO voltages reach their normal operating conditions. This situation can occur when the VDD and LDO voltages ramp up at significantly different rates."

    Unfortunately I do not really have a history with these devices to be able to speak to why you are seeing this 15 ms lag right now and I haven't been able to dig up any information. But I think that is the root cause here.

  • To confirm, this current pulse only happens on power up. And, as I've said, at a rate of about 5% of units, and only at higher temperatures (the lowest temperature a unit has this behavior is 40C, but typically it is between 55C and 70C).

    About the GPIO signal glitch, can you tell me if the GPIO pins would be driving high or low during this glitch where they are configured as outputs? Also, can you tell me how long this glitch typically lasts?

    Secondly, besides the workarounds suggested (capacitance on LDO, and fast VDD risetime), are there any other workarounds you can think of? For example, is there a way to change whether the glitched GPIO outputs are configured as driving high or driving low during the glitch? Or, could using the series diodes of figure 8 in the errata be a solution? Or any other ideas?

    Thanks,

    Mike

  • I'm sending you graphs of of VDD and LDO power on waveforms. One that shows normal behavior and a second that shows our current pulse behavior. The first normal waveform shows LDO follows VDD pretty closely. The second shows LDO lags VDD by quite some time (15 ms).

  • Hello Michael,

    Michael Rector said:

    About the GPIO signal glitch, can you tell me if the GPIO pins would be driving high or low during this glitch where they are configured as outputs? Also, can you tell me how long this glitch typically lasts?

    Secondly, besides the workarounds suggested (capacitance on LDO, and fast VDD risetime), are there any other workarounds you can think of? For example, is there a way to change whether the glitched GPIO outputs are configured as driving high or driving low during the glitch? Or, could using the series diodes of figure 8 in the errata be a solution? Or any other ideas?

    RE: Whether the glitch is high or low, it would glitch high because at power-up the I/Os should be low already. But we don't have data on the duration that I could find.

    Unfortunately we don't have much more detail here than what is in the documentation. The investigation into these errata items were done by other engineers many years ago. While we can guide based on what data we have available and any possible ideas we can think of in general, we don't have any real experience with helping any customers resolve these errata items.

    To that point also, is this for an existing design and if so how did this issue start to be observed?

    If you are doing a new design, you really should be looking at our TM4C products.

    Regarding trying to debug this issue further, one idea that came up to further characterize what is going on here: can you isolate all the I/Os from the rest of the components in the system and see if there is still the high current draw on power up?