Can your program, ever damage an MCU ?? - Page 1
Forum section: electronics / general

author: MathWizard
author_rank: Super Contributor
timestamp: September 26, 2024, 12:41:53 am
content: I know you can set/burn fuses, and with external circuits wired up, you might overheat stuff, or apply the wrong voltage to a pin....But with just power and GND, on modern MCU's, can you ever set something that internally conflicts, and can do bad, unpredictable things or even damage the MCU ??And for port protections, how many MCU's pins would have O/V voltage, or OVcurrent, or over temperature sensing ?I'm sure some MCU's have that on certain pins, but how common is it ??

author: Kim Christensen
author_rank: Super Contributor
timestamp: September 26, 2024, 12:48:58 am
content: I guess you could let a bunch of IO pins float as inputs so they draw a lot of current.Or have code that writes excessively to flash or eeprom and wears it out.Otherwise, on a properly designed MCU, no real damage should happen from crap code.I've never heard of MCU's with built in protection for their generic IO ports against O/V voltage, or OVcurrent, or over temperature sensing. (Beyond the simple diode clamps to Vdd/Gnd)Some MCU's have pins that'll tolerate voltages a bit higher than Vdd, but not excessively so.

author: brucehoult
author_rank: Super Contributor
timestamp: September 26, 2024, 12:49:15 am
content: A program can do things such as reassign pins or change clock rates that make it impossible to connect with the usual debugger/programmer to upload a new program. There will be a window after power-on, but it can be too short to be usable. So the device is not physically damaged, but it is unusable.Some chips, can recover from this by other means. e.g. AVRs have "high voltage programming". I don't know about others.

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2024, 01:12:10 am
content: Extremely unlucky code can change all sorts of factory calibration values. But I don't really see that happening on accident. Those programming interfaces are unlocked by wiring a very specific sequence into undocumented registers. And then the programming process itself is not trivial.This is still technically not a physical damage, since device could be re-calibrated at the factory.I don't think there is a way to cause true physical damage.

author: globoy
author_rank: Frequent Contributor
timestamp: September 26, 2024, 01:18:33 am
content: I wonder if some complex multi-core SOCs could be damaged by a combination of setting too high of an internal voltage and too high of a clock rate (perhaps for too many cores) and overheating it. But maybe they have built-in hardware throttles that would prevent an errant software configuration from setting up a condition that could damage the chip.Or maybe there is a HW bug that could be exploited on some devices like on the recent Intel Core parts.

author: dmendesf
author_rank: Frequent Contributor
timestamp: September 26, 2024, 01:32:32 am
content: Intel just did that...Quote from: globoy on September 26, 2024, 01:18:33 am

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2024, 01:35:07 am
content: Intel case was a manufacturing defect. The CPUs were used at their advertised settings and still failed.

author: globoy
author_rank: Frequent Contributor
timestamp: September 26, 2024, 02:14:19 am
content: Quote from: ataradov on September 26, 2024, 01:35:07 amThis article says it was a microcode bug:https://www.pcmag.com/news/intels-raptor-lake-bug-patch-is-here-how-much-does-it-affect-performanceAnd this article says there was a manufacturing defect but it wasn't the root cause of the big issues:https://www.tomshardware.com/pc-components/cpus/intel-announces-an-extra-two-years-of-warranty-for-its-chips-amid-crashing-and-instability-issues-longer-warranty-applies-to-13th-and-14th-gen-core-processors"The company apologized for its slow response and released a statement reiterating its prior statement that Via Oxidation is not the root cause of the current instability issues. Intel says it first discovered the oxidation issue, which it characterizes as "minor," in 2022. The company says it instituted fixes and enhanced screening in early 2023 and removed all impacted chips from its supply chain by early 2024. However, it does concede that some chips with Via Oxidation defects could have still been on retail shelves as recently as early 2024."But aside from wearing out flash (as has been mentioned) it does seem like it would be hard to do.

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2024, 02:25:22 am
content: Quote from: globoy on September 26, 2024, 02:14:19 amIt is either a shitty design or a manufacturing defect that got worked around by a microcode patch at the expense of performance. And presumably higher performance if why people bought them in a first place.I could understand if the microcode did something that broke the chips, but did not affect performance otherwise. Then it is a just a bug that got fixed.

author: dmendesf
author_rank: Frequent Contributor
timestamp: September 26, 2024, 03:41:18 am
content: In their quest for the performance crown they managed to overvoltage their CPUs by fucking the microcode that controls voltages and clocks, so I think it somehow applies for this threadBTW AMD just launched their 9000 series processors and performance was less than spectacular. Their solution? Microcode to turn 65W processors into 105W processors. IThink I just saw this movie...Quote from: ataradov on September 26, 2024, 02:25:22 am

author: brucehoult
author_rank: Super Contributor
timestamp: September 26, 2024, 04:56:29 am
content: Quote from: ataradov on September 26, 2024, 02:25:22 amThe power controller was giving the cores more voltage than was actually necessary to get the desired operating frequency, and causing damage. I believe that the fix, giving them the correct voltage, should result in the advertised performance with no damage. Unless of course you've already damaged your chip.Apparently the laptop parts, such as the i9-13900HX in my Lenovo laptop, are the same chip but just run at lower voltage and wattage and frequency (supposedly 5.4 GHz, but I've never observed more than 5.3 on mine) that is fine.

author: Jeroen3
author_rank: Super Contributor
timestamp: September 26, 2024, 05:57:45 am
content: You can set the highest level of readout protection and erase the flash.

author: JPortici
author_rank: Super Contributor
timestamp: September 26, 2024, 08:00:30 am
content: I did brick chips in the pastthey all had ECC flash, the trick was to overwrite (while testing the firmware, or later by bugs) some key location that would be loaded at startup (for example, in dsPIC the configuration memory is loaded from flash right after VDD is stable, but if it was overwritten and hamming code doesn't match it will go straight to a hard fault, which if not programmed will lead to a reset which will load the configuration.... you get the drift). Some i manage to rescue by careful timing and entering programming mode before startup had initiated, some i didn't and went to the bin.Chips with internal regulators, especially DCDC, i wonder if you can put them in such a state that they start to oscillate and destroy the chip

author: hans
author_rank: Super Contributor
timestamp: September 26, 2024, 03:15:33 pm
content: Thought experiment; some crystals are using lower drive powers to resonate, like a few hundred uW. Their drivers are usually biased at some DC with a small sinusoidal voltage swing. They also typically aren't rated for high drive powerWhat if you would start driving these crystals between voltage rails? Would there be a resonance point at which these can break? In theory crystals have ultra high Q (hence the low drive power), so what if that could be used to destroy them.In theory you could write a virus program that tunes the internal oscillator, switches them over so the devices remains (somewhat) operational, and then breaks the external oscillator. Or at least to such degree it becomes inaccurate for future operations after a reset.

author: tszaboo
author_rank: Super Contributor
timestamp: September 26, 2024, 03:20:35 pm
content: Quote from: hans on September 26, 2024, 03:15:33 pmIf you can upload code to something, you can just write:while(0);

author: eutectique
author_rank: Frequent Contributor
timestamp: September 26, 2024, 04:03:10 pm
content: On NXP S32K, you can overstress and eventually damage flash if you write ones to already written location(s) -- that's what RefMan says.Or think of an MCU powered by a PMIC, usually accessed via I2C. You can set a very wrong voltage or sequence which could cause physical damage. Not MCU feature, strictly speaking, but still falls under definition of"your program".

author: MathWizard
author_rank: Super Contributor
timestamp: September 26, 2024, 07:46:24 pm
content: Ok so as long as I don't mess up the lock bits on some AVR chip, sloppy code should be fine, and should never hurt the chip. Yeah I never really heard people mention about damaging MCU's, but people do "brick" things like GPU's, when they upload the wrong code to it. I guess there's a bunch of chips in them that are locked off.I know in older cars, you can drive in reverse for awhile, then put the car in forward drive and stress all the drivetrain and burn the tires a bit, on a car that otherwise can't burn tires. IDK if new cars still can do that or not.But when you attach 2 high pins together and turn them on, and the voltage drops a lot, or attach the negative rail to the positive rail, that's not how modern computers do logic.I guess shorting to high pins won't do much, it's just a jumper between two pins at almost the same voltage.

author: radiolistener
author_rank: Super Contributor
timestamp: September 26, 2024, 08:23:58 pm
content: Quote from: MathWizard on September 26, 2024, 12:41:53 amSome MCUs may have OTP fuses that control which features are enabled. If you write to these OTP fuses, you may lose access to certain MCU features. Some MCUs may also allow control of internal voltage regulators. Writing an incorrect value may lead to damage. You should also be cautious when configuring GPIO, when a pin is shorted to ground or the supply voltage may lead to excessive current and damage. In all other cases, there is no way to damage the MCU.If MCU consume high power, there is also risk to get overheating, it also can damage it.

author: MLXXXp
author_rank: Frequent Contributor
timestamp: September 27, 2024, 01:32:24 am
content: Quote from: Kim Christensen on September 26, 2024, 12:48:58 amI think this would be one of the easiest ways to damage an MCU under the stipulated guidelines.

author: westfw
author_rank: Super Contributor
timestamp: September 27, 2024, 06:43:50 am
content: QuoteMicrocontrollers as simple/cheap as the RPi rp2040 apparently let you adjust core voltage and clock rate far beyond "rated specifications."It doesn't seem too unlikely that you could burn one out that way (I don't THINK that they have the built-in overtemp protections of more complex CPUs.)

author: peter-h
author_rank: Super Contributor
timestamp: September 27, 2024, 08:39:59 am
content: The Q is really: if a CPU contains no programmable features, can you mess it up?Because if it has on-chip FLASH thenobviouslyyou can mess it up. Just load some duff code and disable the SWD/JTAG code loadingOn STM chips, RDP2 will do it nicely. Ordinarily I don't think you can disable code loading because SWD/JTAG starts with reset active (it's actually a debugger option, but normally one does use it) so no code can run.Whether you can do damage by misprogramming an internal voltage regulator is interesting but not anything I've worked on.

author: Phil1977
author_rank: Frequent Contributor
timestamp: September 27, 2024, 09:07:26 am
content: What happens e.g. if you connect a medium sized cap to a push/pull output and switch it as fast as possible?Are all MCUs protected against the resulting load or may a push/pull stage burn out? I think especially with programmable in-/outputs it´s not so uncommon to have caps connected there in real life applications.

author: peter-h
author_rank: Super Contributor
timestamp: September 27, 2024, 10:22:39 am
content: Localised heating for sure. The simplified circuits do not show any actual current limit components and certainly no temperature sensing.

author: asmi
author_rank: Super Contributor
timestamp: September 27, 2024, 02:57:16 pm
content: If you grossly mismatch transmission line impedance and a high-speed driver, you can get some really impressive overshoot from reflections, but I'm not sure if it's ever going to be enough to damage driver because ESD diodes will supposedly prevent those overshoots from reaching the actual driver.

author: nctnico
author_rank: Super Contributor
timestamp: September 28, 2024, 04:20:01 pm
content: Not an MCU but I have managed to destroy a Xilinx FPGA through software while developing in-circuit programming algorithms.

author: peter-h
author_rank: Super Contributor
timestamp: September 29, 2024, 07:26:35 pm
content: In an FPGA it should be possible to connect a 10k outputs all together and drive 5k to 1s and 5k to 0s

author: ataradov
author_rank: Super Contributor
timestamp: September 29, 2024, 07:40:30 pm
content: You can't do that internally, I/O driver outputs are not connected inside the fabric. You can only do that if you connect the pins externally. And in that case, just apply mains to the device, it would also kill it.

author: peter-h
author_rank: Super Contributor
timestamp: September 30, 2024, 09:21:55 pm
content: I meant just normal bus contention internally, not shorting out loads of GPIO.When I was doing FPGAs, you would have got loads of DRC errors/warnings however.

author: ataradov
author_rank: Super Contributor
timestamp: September 30, 2024, 09:46:06 pm
content: There is no way to cause bus contention, There are no common busses, everything inside the fabric is multiplexed. There is no physical way to cause shorts.

author: nctnico
author_rank: Super Contributor
timestamp: September 30, 2024, 10:04:42 pm
content: Quote from: ataradov on September 30, 2024, 09:46:06 pmThe older Spartan 200 series have internal busses where you can get bus contention. But don't forget that there may be invalid configurations for modern day FPGAs as well. The software avoids these but it doesn't mean it is impossible to create an invalid configuration in other ways. Having a feedback loop on all flip-flops to toggle them at maximum rate is likely going to produce lots of heat as well.

author: peter-h
author_rank: Super Contributor
timestamp: October 01, 2024, 08:36:58 am
content: On the Xilinx chips I used one could have tri state gates so could create an internal bus. A long time ago. XC3000 / XC4000 IIRC.

author: asmi
author_rank: Super Contributor
timestamp: October 01, 2024, 01:21:04 pm
content: Quote from: peter-h on October 01, 2024, 08:36:58 amNope it's impossible to do as there are no tristate gates inside, these things are emulated using multiplexers as was mentioned above.

author: MathWizard
author_rank: Super Contributor
timestamp: October 01, 2024, 02:25:07 pm
content: Today my new XGecu T48 should arrive. I'm hoping I'll be able to read the memory out of some old MCU from a DVD player or something, but maybe they are all pretty much locked off.I know some old MCU's must be hackable, but yeah I think a lot of the stuff that I hear about that was hacked.....it's actually people getting the contents of a ROM chip, or some stream of data, and then doing coding, to decrypt stuff.I was playing around with some old MCU from a DVD player that powered a VFD. It's a bit broken, or very confused some of the circuits are missing. But I'd love to get inside it, hopefully the T48 will let me do something, anything for a bit of fun. I hope I don't mess up the MCU tho.

author: ejeffrey
author_rank: Super Contributor
timestamp: October 01, 2024, 07:03:55 pm
content: Quote from: asmi on October 01, 2024, 01:21:04 pmThe XC3000 had acual three state buses internally for interconnect. Take a look at chapter 7 of this datasheet:https://www.mouser.com/datasheet/2/903/3000-1595472.pdfIt specifically cautions that the user needs to prevent multiple simultaneous drivers on the bus.That's a very old part and I don't know when xilinx stopped doing that. I'm pretty sure the Spartan 3 didn't have internal tri state buses which was the first FPGA I actually used. Now days it's indeed all done with muxes, and if you write logic that looks a tri state bus with multiple drivers, it will turn out to be a priority encoder and if two drivers are on, whichever one the tool assigned higher priority will be selected.

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 01, 2024, 08:11:15 pm
content: This is something that can only be found in pretty old FPGAs. I don't know how the synthesis tools would make use of that exactly, having never used one of these.I suppose that writing multiplexers in HDL in a "high-level" manner would probably make proper use of the tristate busses and avoid any contention, but that if you'd directly control the tristate enables with signals (a lower-level approach), then you could mess it up and damage the chip.

author: nctnico
author_rank: Super Contributor
timestamp: October 01, 2024, 09:02:42 pm
content: Quote from: SiliconWizard on October 01, 2024, 08:11:15 pmYou have missed out on a wonderful feature thenI have used these plenty in my first years doing FPGA design. Bi-directional connections (busses) inside these FPGAs work like a databus between a CPU, memory and peripherals. In VHDL you'd use the 'Z' state combined with a select signal to tell the synthesizer create a tristate-buffer to drive a net. It is not fast but gives a pretty efficient use of internal routing resources if you can connect like 20 functional blocks with logic inputs / outputs to a single line.

author: Mia Barn
author_rank: Newbie
timestamp: October 02, 2024, 07:29:47 pm
content: Yes, burning is possible thriguh the power and ground pins only. I recently burnt my ESP32

author: ataradov
author_rank: Super Contributor
timestamp: October 02, 2024, 07:36:20 pm
content: This was not the question. It is obvious that it is possible to kill anything with incorrect power supply. The question was about software on the working hardware.

author: Dave
author_rank: Super Contributor
timestamp: October 02, 2024, 08:12:33 pm
content: You can wear out the memory cells in flash if you repeatedly write and erase the same pages over and over again. Not a matter of seconds or minutes, but you'll eventually get there if you do it rapidly enough.

author: macboy
author_rank: Super Contributor
timestamp: October 03, 2024, 06:55:08 pm
content: You remind me of the infamous HCF - Halt and Catch Fire instruction.https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing)#OriginsModern designs should not contain such illegal instructions.

author: peter-h
author_rank: Super Contributor
timestamp: October 06, 2024, 05:03:50 pm
content: QuoteThe XC3000 was moved to a smaller geometry silicon (which made it run much faster and broke a lot of designs) about 20 years ago, and I was still able to buy an XC3064 about 10 years ago, from a Xilinx disti.

author: Foxxz
author_rank: Regular Contributor
timestamp: October 06, 2024, 05:38:09 pm
content: I had a 68HC11 or 12 program that started writing data to the beginning of RAM and didn't stop when it hit the last RAM address. I don't know if it burned some efuses or some eeprom programming values but I was never able to write a program to the eeprom again. I was still able to load programs to RAM.