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.

EK-TM4C123GXL: Tiva dead after something went wrong while dealing with usb_host_msc example

Part Number: EK-TM4C123GXL
Other Parts Discussed in Thread: EK-TM4C1294XL, , TM4C1294NCPDT

Hi,

So...I was trying to write a text file on my Tiva device (EK-TM4C1294XL), after a couple of time trying to understand how the usb_host_msc works, I decided to create a function that writes some text file for logging purposes. Everything was running smooth so far, except that in the beginning I was only printing some random strings.

Then I decided to make a loop to write the string multiple times in the file. Flashed the new code, didn't work the way I expected, tried to modify the code and that was when the compiler refused to load the program on my device. I tried a couple of times until I realized the MCU core was very, very hot, and obviously, dead ;-;

This was the function I was executing at the time:

int
Cmd_write(int argc, char *argv[])
{
    UINT bw;

    char algo[] = "Alguma coisa \n";

    int var = 0;

    while(var < 12)
    {
    if(f_open(&g_sFileObject, "arquivo.txt", FA_WRITE | FA_OPEN_ALWAYS) == FR_OK) {   // Open file - If nonexistent, create
            f_lseek(&g_sFileObject, g_sFileObject.fsize);                   // Move forward by filesize; logfile.fsize+1 is not needed in this application
            f_write(&g_sFileObject, algo, sizeof(algo), &bw);             // Append word
            UARTprintf("File size is %u\n",g_sFileObject.fsize);              // Print size
            f_close(&g_sFileObject);                          // Close the file
            if (bw == sizeof(algo)) {
                UARTprintf("Op successful\n"); 
            }
        }
    ROM_SysCtlDelay((120000000/3)*0.15f);
    var++;
    }

    return 0;
}

Also I'm attaching a image that shows how the USB stick connection was made. How that happened? I was planning to use the USB stick in the TM4C123, but now I'm afraid of killing my other Tiva as well...not to mention that some hardware modifications is required for that device.

Thanks

  • Hello Helder. Your photo does not show the EK-TM4C123GXL but the EK-TM4C1294XL instead. Need to ask you something: Is the area/room/office that you are working with the Launchpad anti-static protected? Is your floor wooden/cement/neutral polymer OR covered with artificial imitations of these materials? Maybe is not your code but the static in the area that fried your Mx core. How to you supply power to your board. Are the jumpers for power supply correctly set?
    John

    P.S. Seems that you power the USB flash-stick from Launchpad. Does your power source support the needed mAmperes? 

  • Oh, I'm sorry, it is the TM4C1294 that I burned up (not sure I can change that now). The place I work is not anti-static protected, but the floor is wooden. I supplied power via the ICDI using the computer USB port, which I believe that supports at least 500 mA.
  • Hi Helder,
    Sorry to hear what happened. When you said the part is dead I guess the power LED on the board is not lit anymore, is it correct?
  • Helder Sales said:
    ...TM4C1294 that I burned up

    Feel your pain - yet do NOT be so quick to conclude that the device is (truly) dead!   Firm/I have recovered multiple MCUs (from multiple makers) which have suffered (brief) over-heated "episodes."  (Note: this is NOT to suggest that you target this MCU for "human implantation or deep space" - it may be suitable (still) for (much) of your continued development.)

    I'd suggest that you power that board via a Lab Supply - which can "current-limit" - and power the MCU board with "nothing" externally connected.    You may wish to set the supply's current limit to 10% over the board's rating.   If the board draws current - substantially beyond its spec - that then proves a far better indicator of board's (life or death.)   I'd give your board 60:40 odds of (not) having died.   (unless that over-heat condition - passed un-noted -  for a LONG time.)

    As you appear "locked out" now - the LMI Flash Programmer provides a method to (attempt) to restore the device to operation - yet I'd launch that attempt only after the current measurement indicates "board in coma" rather than death.

    Note that while the USB spec lists 500mA - that's not always fully reached (really - who is going to measure) and your board & its external device may draw "too much current" upon power-up/connect.

    During development - most always a "real" Lab Supply - properly voltage & current limited - can prevent such misfortune.   (and will provide an excellent "display" of typical board current)    Choosing connection "ease" (PC) - over "board health & current monitoring" (Lab Supply) - has a downside as you've (painfully) discovered...

  • Charles Tsai said:
    Hi Helder,

    Sorry to hear what happened. When you said the part is dead I guess the power LED on the board is not lit anymore, is it correct?

    Actually, the power LED was functioning normally.

    cb1_mobile said:
    As you appear "locked out" now - the LMI Flash Programmer provides a method to (attempt) to restore the device to operation - yet I'd launch that attempt only after the current measurement indicates "board in coma" rather than death.

    I've tried that (thanks for the tip), though I don't have any way to limit the current (but I read 67 mA  from the multimeter through the JP2). It worked! BUT...it seems that the board is damaged, I tried to run some examples like Timer and Blinky, and the on-board LEDs (except power LED) not light up anymore, only the serial comm was working and the Timer0. 

    Oh man, I'm not confident enough to use a USB stick again in any board...not without a lab power supply or some means  of monitoring the current (multimeter not always works, sometimes the UART doesn't function properly with it).

  • Hi Helder,
    The on-board TPS regulator has current-limit. Since you just said you can connect to the target and run some code, i..e serial comm then I don't think the board is dead, at least not totally. Can you please check on the scope of the GPIO pins (PN0, PN1, PF0, PF4) that drive the LEDs to see if the LED diodes are bad or the GPIO pins are bad?
  • Charles Tsai said:
    The on-board TPS regulator has current-limit.

    May I (respectfully) disagree with this (assumed) "Lab Supply unnecessary" direction?    It is not "best practice" to RELY upon the DUT (device under test) to, "Protect itself!"   And - the effectiveness of that "on-board regulator" - NOT being specifically designed for this MCU board - must remain "questionable."

    Note too - poster reported substantial over-heating of his MCU - thus the case AGAINST (any) on-board, general, current limiting scheme stands very much in evidence.

    Lab supplies surely have a purpose - may be precisely adjusted to the user's "exact" needs - provide FAR BEYOND the "promised" current (yet safely limit it) offered by PC's USB port - clearly display current draw - and again - relying upon (any) board or device to "protect itself" presents high risk!    Convenience (usually) comes at (some) cost - users must recognize that limitation...

    Note that two here claimed "dead" - one advised, "Not so fast" - and poster's latest reports indicate that while somewhat, "disturbed" - the MCU may still be usable for (some, perhaps many) tasks...

  • Hi cb1,
    Point well taken. I check the TPS datasheet. The 'typical' current limit is at 1A.
  • Thank you, Charles.

    Firm/I have sufficient experience to have long recognized the value of a Lab Supply:

    • knowing the actual value of the, "normal" current drawn by a board, "under development."   
    • easily noting the "current burden" (addition) caused by "Peripheral Enabling" (likely slight) and by, "External boards or devices."  (may be large)
    • quick acting, adjustable current limit which "signals" when it has "tripped"  (so often identifies an issue EARLY - preventing damage)

    We note that poster stated, "PC's USB port typically cannot provide beyond 500mA" - thus the "1A" trip-point of the on-board regulator was unlikely to be reached.   Lab Supply set to 10% above board's rating (maybe 100mA) clearly provides greatly enhanced board protection!   (While informing user/developer of "normal" current draw - during ALL aspects of development...)

  • Charles Tsai said:
    Can you please check on the scope of the GPIO pins (PN0, PN1, PF0, PF4) that drive the LEDs to see if the LED diodes are bad or the GPIO pins are bad?

    PF0 and PF4 is functioning normally, but PN0 and PN1 is stuck at 1.95 V. I guess I'll have to sweep the entire board to see what's left intact.

    cb1_mobile said:
    Lab Supply set to 10% above board's rating (maybe 100mA) clearly provides greatly enhanced board protection!   (While informing user/developer of "normal" current draw - during ALL aspects of development...)

    I always wanted a lab power supply, but with its price I can buy at least 4 EK-TM4C1294s (and I don't know if the lab supply will have enough precision, i.e. reading a few mA). With that in consideration, I always rely on phone chargers to do my things (though never used on a Tiva), recently I modified one to make it variable (1.2-4.2 V) using a potentiometer and a LM317T.

    Also, I discovered that USB 3.0 can reach 900 mA, and my board can supply 1.5 A with a driver installed, though I have not installed the driver to make the 1.5 A avaiable. Still, connecting a pendrive would draw too much current?

  • Hi Helder,
    You might want to also check if the LEDs are burned out. 1.95V is supposed high enough to turn them ON. Looking at the schematic there is 330ohm series resistor to protect the LED. So not quite sure why/if they would burn out.
    Looking at your code again, I don't really spot anything wrong. Can you rerun your code again? Are you sure Cmd_write() was the only thing and nothing else that you modified before the chip became hot? Are you calling Cmd_write() in a loop or only call once within which 12 iterations are looped to write to the FatFS. I know you may be a bit wary to rerun the code. But the board is like walking-wounded so I guess it does not hurt to try again. This time I will suggest you place breakpoint inside the loop first to see what happens.
  • LEDs are dead, they're getting 1.9 V but no light (and the pins even in low state gives 1.9 V). Apparently the device USB port is also dead, because it doesn't read the USB stick anymore (the pendrive LED doesn't blink and the program says FR_NOT_READY), so I can't test the code. And I'm sure that I did not modified anything else except Cmd_write().

    One thing I noticed is that all programs loads up almost instantaneously (even the 50K ones that took about 1.5 - 2 seconds in the past), might be indication of another problem.

  • It is hard to imagine "how" several Leds - w/330Ω resistors in series - could have been damaged. I would suspect a more general "power supply and/or distribution" issue - perhaps the "far side" of those Leds has lost its ground connection. Suspect that you measured 1V9 @ the MCU side of the series resistors - it would be useful to measure the voltage between ground and the Led pin which is "tied" to ground. Also - it would be useful if you could remove one of those 330Ω series Led resistors - and then toggle the MCU pin driving that circuit - and report if 1V9 (remains) @ that GPIO pin - both when ordered "high & low."

    A quick/dirty check of the Leds would see you "lift" the 330Ω series resistor (so that only the "Led side" of the resistor remains connected) and then (briefly) apply 3V3 to the "raised, isolated" side of that 330Ω R.   You must NOT allow that 3V3 to reach the MCU - this is (just) an Led check.   (and a check of the GPIO output capability of the pin driving that Led.)   Should the Led "light" (as I suspect it will) the GPIO's output circuit has failed.    (killing the Led - again - w/such protection in place - is hard to explain...)

    You earlier reported ~67mA as the board's current draw - is that still the case? Have you (recently) measured VDD at the MCU and also VDDC? Are they (both) to spec?

    Very rapid program load may indicate that the program has not "really/fully" loaded. Have you scanned through the Flash memory (especially toward the upper end of code) - after that program load - and verified that your code is (really) there?

    As to the USB port - I'd bet that either its ground or positive voltage connection @ the USB receptacle is inadequate.

    Most signs here point to a "Common Power Supply issue" as your board's key fault...

  • Hello all.
    The power to the board, if it is supplied by the ICDI connection, IS NOT always enough (the current is not enough) to support a USB flash drive connected to the OTG port. And although the connection of the U5  to the TM4C1294NCPDT is done through the protection of the U4 IC which will cut supply if current drain ecxeeds 1.1A from the processor's side, this is not the case for U4 which supplies directly the 5V rail and the OTG USB channel. So It may be the case that only U4 is slightly damaged. This can be tested if you supply power to the board through the OTG port with a mobile phones 2A charger. But need to put jumper JP1 at the OTG position. If processor works then the problem might be with a slightly or fully damaged U4, which in turn may have result into the damage of the USB OTG subsystem.
    Try it and tell us.
    All the best,
    John

  • May I note the "inside expertise" of poster John's writing? He's supplied great - specific board - detail.

    I agree w/most everything presented - except the direction to use the "mobile phones' charger." While such a device (solves) the inadequate current delivery (from the PC's USB port) NO "User Adjustable, Current Limiting" is provided!    (and most such chargers can support (easily) double (or beyond) their rated currents during transient peaks)    Thus - such "higher-current capable" supply presents a "dual-edged sword" - desirable due to that added current sourcing capacity - and "undesirable" (due to the destructive potential) presented by that (same) added sourcing capability!

    Indeed a lab supply adds cost - yet does the "repeated risk" to MANY Boards - AND the lack of quickly/easily/regularly KNOWING your board's "Current Draw" not justify that investment?    (not to mention - the (significant) loss of time, funds, morale - when, "Unlimited Current Flow" leads to Disaster!)

  • Hello to everybody.
    Thank you cb1_mobile. I agree that mobile pone's USB 2A power supply is not the best option but one, if anything else not handy, may rather quickly identify if the power supply subsystems are somehow in trouble. In any case, one can successfully bypass for good both ICDI and OTG power supply paths. Even if does not use a booster-pack, he/she may use an external power 5v/3A supply and connect it onto the 5volts rail of EK Launchpad while moving jumper JP1 at the booster-pack position. For 5-7 $ one can buy reliable tiny 5V/3A ps from many suppliers. A 2.5A fuse socket in the middle for 0.5$ would also be a good choice, if not a must, in addition.
    All the best,
    John
  • May I note that, "most all fuses" do not respond quickly or reliably enough to, "protect the user's board and system!"   (Not to ask - "How I know!")

    As stated - a "proper, adjustable, current-limiting Lab Supply" will pay for itself in, "board protection & user awareness of normal, board current levels."

    All else serve as "short-cuts/band-aids" - and leave users (extremely) vulnerable...    Insurance exists for good reason - so too - Lab Supplies...

  • Hello cb1_mobile and all. I totally agree with your point cb1_mobile, given that everything happens on our desk/workbench. But when we need to hand the module (Launchpad or a TM4C129x based board) over, along with our firmware and needed peripheral hardware, to a client as a solution in a box, then we need to escort this box with a ps of the type I'm referring to. There are types of fuses that burn fast enough to protect our product. Also, since I had the privilege to be a, for long-years,  friend of RAP (Bob Peace) I have taken very wise lessons from him regarding mostly very serious analog and analog/digital issues. One of the most important was one that goes with your view that the most wise dollars to spend are those for buying the tools we must have on our workbench.

    All the best to all.

    John

    P.S. The other most important lesson was: "read the #$@ */!!@# manuals" :-)

  • John - indeed it is rare for one to, "Ship the Lab Supply" w/the finished product. But - during "Design/Development" such Lab Supply stands "sine qua non" (supreme.)

    Firm/I have MANY of those (past) blue data books - analog ones often featuring the (unique) circuit design "artwork" of RAP.

    May I add (to your list of Proper Tools, RTFM) the techniques defined by "KISS?" One small, tightly focused/monitored step at a time, proves (almost always) "best ticket to success!"
  • Yes, yes cb1_mobile, I have almost all that blue-books of NATSEMI of that time and the CDs after the books were not printed any more. I also have all books written by RAP on ANALOG. It's a THESAURUS indeed. And also a big yes to the Keep It Simple %&^$# principle. John
  • Hi people,

    I tested the Tiva with the power select jumper in the "OTG" position. It worked. Not sure why the pendrive is not getting enough current from ICDI connection anymore though.

    Also, I tested the LEDs and they were connected to ground. So I removed the LEDs and temporarily placed a non-SMD and it lighted up. The pins are getting 1.9 V with or without 330 Ω resistor.

    I've checked the upper end of code in the memory and it's there. I'm not sure if I checked correctly, I used the "used" value of the .map file to search and rolled backwards.

    I'm really considering buying a lab power supply, it's just a matter of time. But I'm buying other things first, like soldering iron, jumpers, 1mm solder tube, etc, and these things adds cost. Not long ago I was soldering things with a 3mm solder without flux, and a almost broken soldering iron (used a thick cooper wire to replace the tip). My dream is to have a oscilloscope and a function generator along with the lab supply...

    Also, what is "KISS"?

  • That 1V9 is the (usual) voltage drop seen across a (non-blue or white) Led when it is on & conducting.    I'm unsure if you're noting that the original smt Leds no longer illuminate - is that the case?    (earlier it was requested that you "lift" one end of the 330Ω series R - and apply 3V3 - that "removes" the MCU from driving responsibility for the Led.)

    Have you "re-tested" those MCU GPIO - earlier tasked w/driving those board Leds?   Those pins should produce ~3V3 when "high" and ~0V when "low."   (when driving a light load)

    I cannot explain the (apparent) "quickness" of your code download.   Under our IAR IDE we can easily read (and display) the flash memory - an abbreviated code load is the only thing I can think of which would "speed" that download.

    KISS is the direction to, "Keep It Simple Student" (other - less diplomatic words (sometimes) replace "student.")   The guiding principle is to move slowly, cautiously - attempting to minimize the "field of play" (i.e. better focus) so that fewer demands are created.   As an example - you would develop your project (or write your code) in deliberately small (again highly focused) segments.   This "narrowing" of a large project into far smaller, constituent parts - most always, "Speeds, Eases & Enhances" project completion & results...  

    The simple act of dividing a project into "segments" - is in itself - of high value.    When forced to think in this manner/level of detail - necessary segment interrelationships become (far) more evident - and areas of greater difficulty are revealed in highlight.    As each segment nears completion - the reduced size & tight focus - speeds & eases, "Segment Testing."    Only when segments have been successfully tested are they admitted to the "project's whole" - and this, "Pre-Test prior to Joining" spectacularly improves upon, "Do everything together - at once - and ONLY test when (finally) complete!"    (And - during such "everything heaped together" testing - be SURE to "Stand far back" (ideally w/Fire Dept. on call) and strong wall between yourself & Boards being tested...)

    That "all at once" method is often practiced - seems "natural" - yet when, "Multiple parts are produced (outside) of the discipline enforced by KISS" - and then brought together - results most always disappoint - and the job of trouble-shooting is made immensely more complex.   (i.e. where does one "start?")

  • The original LEDs no longer illuminate. I recall that applying 3V3 to the LED after lifting the resistor produced a very faint blue flash. The GPIO remains 1V9 with and without both LED and 330Ω resistor.

    I tried flashing a 159k code, it seems that the program is flashing correctly, the speed is a little faster than before, but acceptable I think. Though I have not modified anything in CCS to speed up the load. Crystal frequency still 8 MHz (this frequency is from what crystal?)

    Thanks for sharing this "KISS" method, it is very interesting. I'll try this not only for writing code, but for developing other things.
  • Unless your board's Leds were "sub-standard" it is hard to account for their destruction. Had you (actually) measured those series resistors? (330Ω noted) Even if 12V was applied to the resistor - 30mA would flow - which usually would not kill the Led if applied briefly. This raises the odds of ESD and/or "reverse bias" of those Leds - again (only) IF those series resistors (really) were 330Ω!

    If the GPIO is truly "isolated" - and 1V9 results when configured as GPIO Output - and set high - (tech word follows) dat GPIO ist kaputt!   Often - other GPIO on that (same) side of the MCU may also be impacted. (wise that you test as - most always - GPIOs on the (same side - there are 4 sides) draw power from a common power rail (which is isolated from the 3 other sides!)

  • They are 330 Ω.

    Some pins are getting 3V3 no matter what, like PP3, PB4. There's also another strange behavior, sometimes all pins (except the ones stuck at 3V3 and 1V9) go to 1V5 in random periods of time. I also measured 2V5 in the 5V pin and 1V2 in the 3V3 pin once.
  • May I suggest that it is now, "time to dress in black - hire a hearse - and pray over the fallen body of that MCU."

    Perhaps even worse - our not "identifying such failure's cause" - leaves your future developments at (equal) risk - does it not?

    I've outlined the methods many follow to prevent such misfortune - I would avoid use of that PC & USB Port (to supply) board power to your future projects...
  • Requiescat in pace Tiva EK-TM4C1294XL (2016-2017)

    Well, I'll try to find alternatives to supply board power, and next time I'll use the EK-TM4C123GXL since it's cheaper. Actually since I depend on the PC USB port to use the console, I'm not sure how I would supply power to the launchpad externally (Tiva 1294 at least has the BoosterPack power select).

  • I believe that most such boards here provide the means for you to introduce, "Safe, Current-Limited (w/current (both) monitored/displayed) power" via a means (other) than the USB cable. (this may involve "breaking" the 5V path w/in the cable - retaining Gnd & the USB channel)

    Good read/review of the board's schematic - then board's silk screen - should identify, "Safer, Power Entry" locations...
  • Hi Helder. At page 11 of the EK-TM4C123GXL manual, @ 2.2.1 says that with the switch you can select power from a USB device. If that device is just a 5V/3A RELIABLE psu with USB output, you can supply the 5V VBUS from that and use the ICDI usb input just for console/debug/jtag as usual. Also you can supply 5V directly at pins 1&2 of JP3 but then, power switch must again be in the +USB vbus position BUT no other usb self powered device should be plugged in this USB port, except from flash-memory sticks or other USB stuff that ARE NOT POWERED by themselves but take power from the board. But SOS: The board silk-print on pin 1 of J3 says 3.3 volts while at the 1st schematics page it is shown as +VBUS (5V) and J1's pin-1 is shown as 3.3V instead. Let us all have someone from TI clarify this. [You can check it by your self also with a voltmeter on PIN-1 of J1 & J3 when board is powered from ICDI.]
    Have fun,
    John
  • Excellent detail, John - thank you - appreciated.

    May I note - that at least on the few "EK-TM4C123GXL" boards my firm has - there are dual, (side by side) silk-screen markings - which attempt to identify the functions of (both) board columns: J1 & J3.   And - at least on our boards - J1-1 is marked 3V3 while J3-1 is VBus.   (these 2 columns reside on the left edge - columns J4 & J2  (which admit (only) Gnd) on the right edge.)

    That reduced size - side by side marking - may be hard to note.   Those double row header pins expand board I/O - but at the cost of silk-screen legibility...

    On our boards the, "Power Select Switch" allows the choice of, "Device (to the left) and Debug (to the right)".    You may have improved upon my suggestion of "clipping" the 5V lead w/in the "Debug USB Connector" - should the "Power Select Switch" break the 5V (via USB) power entry path...

  • Thank you cb1_mobile. Yes you are right. It is printed 3.3V VBUS in the printed guide's photo and by mistake I interpreted it as '3.3v is the VBUS'. Mea culpa.
    John