Did I brick my part by erasing FLASH with LM Flash Programmer?

Hello Dave,

The sequence you have specified should not cause such an issue. I have used the process to upload a file. But I am not sure which Erase button you are talking about next to to the Upload button?

Regards
Amit

The Erase button is located in the upper right corner in the Flash Utilities tab. Try clicking in any of edit boxes. If the Erase button was not in focus before, it is now. Press return while the cursor is in a edit box and watch LM Flash Programmer erase your flash. This behavior is repeatable on my LM Flash Programmer. It is build #1613.

I know the read flash function works because I have used it successfully as well. The difference is that I used the Browse and Upload buttons before instead of pressing return after typing in the edit box. I was hoping I could simply re-program my board after the accidental erase cycle, but no joy. Have you ever had a situation where you could not unlock the flash and re-program a device? Do you have any other suggestions that might resurrect my brain dead part?

Hi Amit,

I feel this poster's pain. Might it be that his ICDI MCU has been disturbed - yet his main board MCU survives? (note firm/I neither have nor desire TM4C129)

Should he not be able to "break the connections" between ICDI MCU & target on his board - and then program the target via "some other means? At least - in this manner - the bulk of his board's value/functionality has been salvaged...

Hello Dave

Thank you for the explanation. Can you check in the Device Manager that when the launchpad is plugged in, the board enumerates with Stellaris ICDI drivers. This will help ascertain if it is the ICDI got disturbed or not.

Regards
Amit

Hello Amit,
Yes, the Launchpad enumerates with ICDI drivers. It shows up as "Stellaris In-Circuit Debug Interface" with "Stellaris ICDI DFU Device" and "Stellaris ICDI JTAG/SWD Interface".

I did not mention how I have my target board connected and that information might be important. I have the Launchpad TM4C1294 device disabled by removing JP1 (Booster Pack Power). I am programming a (now dead) real target device on a separate board by means of a cable connecting the JTAG pins from Launchpad to the JTAG pins of the target device. This has worked well for a long time without issues.

I am using LM Programmer set to "ICDI (Eval Board)". I am not running my target in any kind of USB DFU mode. There is no USB device cable plugged into the target nor is there any means of doing so as I only have a USB host connector on the target board.

Regards,
Dave

Hello Dave,

Thanks for the info. Can you check that on powering up the remote board, does the TDO toggle w/o performing any JTAG access?

Regards
Amit

Hello Amit,
Thank you for responding so late on a Saturday night -
No, there is no toggle on the TDO line from power up. There is a 10K-ohm pullup R on all JTAG lines. TDO appears to rise via pullup force with no active toggle.

A little more info:
There is plenty of activity on TDO as a result of any attempt to talk to the board, but LM Flash Programmer always responds with "Unable to initialize Target". All JTAG signals are clean with no evidence of contention.

Once again - feel (poster's) and (Amit's) pain.   Perhaps this (new) diagnostic method may add insight - help resolve:

Have you another identical - or vendor eval/LPad board - which you can attach (in place of) the now failed board?   It must be that one - or more - of the following prove true:

• the ICDI MCU and/or board - used to generate the JTAG signals - has become (somewhat) "disturbed."   (it clearly has (some) functionality - yet total functionality is unknown.)
• the target MCU and/or board has become "disturbed."
• the connecting cable and/or attachment headers/receptacles and/or one or more JTAG joints/traces on the "target" have become "disturbed."

Is it not productive (and fastest & easiest) to attach (another, "known good" target board) to your "ICDI based JTAG" (board & cable set-up) and attempt to connect, program & debug?   Further - employing (another) method to achieve that, "Connect, program & debug" objective can determine "if" your (existing) "ICDI based JTAG" (board & cable set-up) vehicle has become flawed.   Active posters Robert, f.m. & cb1 all favor the Segger J-Link - clearly a superior, "Connect, Program, & Debug" JTAG/SWD probe/tool.

May I note that - thus far - "KISS" has been bypassed - multiple variables are in play - and the method (herein) suggested attempts to better focus by "limiting the playing field" (per KISS) so that (some) variables may be eliminated (or confirmed) as, "suspicious."

Hello Dave

So the device is working fine if there is no free running TDO toggle after a power up and no JTAG connect being attempted. Please make sure that the LMFlashProgrammer Unlock Sequence is followed correctly, as it requires power and reset to be sequenced. Also do check that the JTAG signals are toggling at 0 and 3.3V toggle. Anything lower than that would mean a possible bus contention.

Regards
Amit

Amit Ashara said:

So the device is working fine if there is no free running TDO toggle after a power up and no JTAG connect being attempted.

Hi Amit,

May I ask if that (quoted) is an, "established "A-Ok?"   (I don't believe it to be adequate.)

"A-B" testing - as dictated by KISS (and described, above) - seems vastly superior to discover what (really) works (or fails).

Hello Amit,
Yes, all JTAG signals have proper logic levels from 0 to 3.3, clean edges, and no indication of contention or other electrical problems whatsoever as measured directly on the pins of the brain-dead target device. I am no stranger to the unlock sequence as I have successfully performed it many times. The device acts like it is locked, but executing the unlock sequence has no effect. Changing Launchpad programming boards has no effect either. It is hard for me to believe the part is completely dead because there is no TDO power-up toggle, and TDO is quite responsive in response to JTAG inquiry.

I will let you all know if I find a solution to this. Please advise with new tests or suggestions if you think of any. I will replace the part next week if there are no other suggestions. I am really at a loss to figure out what happened. This is a board that has been operating very well for months, then went dead after the accidental erase cycle. I do not want to try repeating the accidental erase as described in my initial post as I do not want to risk frying another Tiva chip, but if someone wants to risk that I would be interested in the results.

cb1: Thank you for all of your comments and recommendations. I have verified that two Launchpad programmers are working fine because they have no trouble programming their own on-board devices. After scope measurement verifications described above and the prior history of the board, I would argue that taking this much further would approach Einstein's definition of insanity.

Regards,
Dave

Dave 1024 said:

taking this much further would approach Einstein's definition of insanity.

Agreed - others & I (have) tried to offer assistance - and "Do feel your pain."

As to insanity - forum management invites, encourages & rewards the always uber helpful, "Does NOT Work!   Many (most) posters are not as thorough, schooled, and persistent as are you - and left "Unguided" the cry of, "does not work" echoes across this (unguided) plain...

Now - as one final thrust - you are in (slight) violation of KISS by, "Programming their own (self-connected, via pcb traces) on-board MCUs.   KISS dictates that you must (successfully) program (another) board via the "identical cable & set-up" which (now) fails w/your present, "board under test."   Bypass of that cable & set-up removes that assembly from (proper) scrutiny!

Hello Amit,
VDDC reads properly at 1.2-volts. There is no activity on any of the clock pins. FYI: There is a 25MHz crystal on OSC pins, XOSC is not connected.

Thank you for the explanation about the TDO toggle - I did not realize that meant the flash was locked. Good to know.

Regards,
Dave

Hello Amit,
It looks like you were on the right track with the oscillator. I was able to get the board working by "messing with the oscillator". I found that removing the caps across the two crystal pins allows the part to program properly. I will check the value of those caps when I get into the office tomorrow as I do not have a capacitance meter here at home. The crystal is P/N ABM11-25.000MHZ-D2X-T3 with 14pF caps external. 14pF sounds a little high to me, but I don't have my design notes here. I remember calculating that value per recommendations in an application note somewhere.

The only thing left is to understand what happened. By erasing the flash, does the part execute a boot loader that a new part would not? By using LM Flash Programmer to erase the flash, does it erase EVERYTHING including a boot loader that would otherwise be present? There have been many boards made like the one I have here and they have been working very well with no programming issues. It would be nice to know what is going on, but I don't mind a pair of shrugged shoulders either.

Thank you so much for helping solve this problem over the weekend - I do appreciate that.

Regards,
Dave

Hello Dave,

Could it be a case of electrical overstress or a cold solder hitting the device at the same time as a Flash Erase?

Another question that it prompts is that since the 25MHz crystal is used and it is a TM4C1294NCPDT, has the RBIAS resistor been installed (there is an already published errata on the same)

Regards
Amit

Hi Amit,
The workmanship around the crystal looked pretty good even under 30X magnification. I do not believe soldering was an issue, but who knows. Maybe there was something going on under the crystal package that I cold not see since this particular crystal was soldered with a hot air tool; it was not oven re-flowed so who knows what was under the device. However, I don't know why it would have worked for the last couple months as my engineering board being abused, thrown about like a Frisbee, and programmed a million times if there was a problem with the crystal circuit.

I did manage to get a 200-ohm series R in the design after looking at the Launchpad schematics so that was not an issue. The only thing I can think of is that erasing the flash caused a different dynamic requirement on the crystal circuit, but I don't know what that would be. I will keep a close eye on things for a while. I will repeat the accidental erase process to see if I can shed more light on this before releasing the design to production. Perhaps that exercise will result in better matched load caps, or a better RBIAS value. In the mean time I will mark your reply from 2:58 this afternoon as the verified answer.

As always, thank you for your help.
Dave

Hello Dave

A 200 Ohm RBIAS or 200 Ohm Crystal series resistor?

Regards
Amit

Hello Amit,
Whoops, my bad. I meant 200-ohm series crystal resistor. RBIAS is N/C per the data sheet, but now I see what you are talking about in the errata documentation. Thank you for pointing that out! I will find a way to get that installed.

Thanks again -
Dave

Hello Dave,

I believe the issue that you are seeing is the same as I saw, when I erased the device without the RBIAS installed and a 25MHz crystal on the EMAC+EPHY enabled part.

Regards
Amit

Hello Amit,

Yes, that makes sense after reading the errata. I have already modified the design to add the RBIAS part. I conveniently have a ground via in front of the RBIAS pin so adding a 0402 part there is not a problem.

Note to self: Read the errata!

Thank you for finding this problem - it is much appreciated.

Regards,

Dave

Hello Dave

Glad it got you working again on your project. It wasn't an easy find when we first ran into the issue almost a year and half back

Regards
Amit