[wtallis]

> How could custom software destroy a phone, a computer, a TV, a printer?

The problem with your question is that you replaced the word "firmware" with the word "software" when the distinction between the two is the answer to the question.

[matheusmoreira]

I don't see the problem at all. Firmware is software.

I can see how defective software could damage industrial machinery but I'm having trouble imagining how some TV could possibly be damaged by software. Many consumer devices don't even have moving parts.

[petsfed]

It is very tempting (and very easy) to think about firmware as simply software that you can update willy-nilly and at will, and things will always go back when things go bad. But there is a reason that most embedded firmware engineers are on their org's hardware team, and not software team. If I push a change that requires a JTAG to reverse, then from the customer's point of view, it is damaged.

The bootloader that allows you to revert back to prior firmware, is itself firmware. If that gets broken by a firmware update, then your device is effectively damaged.

[cesarb]

> Firmware is software. [...] but I'm having trouble imagining how some TV could possibly be damaged by software.

It's not very hard to imagine. For instance, most embedded chips have several "general purpose" I/O (GPIO) pins, which can be configured as an input or as an output; their usage depends on how the chip was wired into the circuit, and very often, they're shared with "alternate functions" like a serial bus. Configure them incorrectly (as an output when they should be an input, for instance), and you can easily create a short circuit, burning that pin or even the whole chip.

[Dylan16807]

Is that particular risk common? I would generally hope that I/O pins put out few enough milliwatts that they can be shorted safely.

[HALtheWise]

Yep! Most microcontrollers will sustain permanent damage if you short an output pin for any significant time. You could probably design a microcontroller that didn't do this, but it would require putting a big resistor in line with the pin (decreasing responsiveness and max power output) and/or adding a lot of circuitry and increased cost to defend against a risk that's not a big deal when the chip is being programmed by a competent embedded engineering team.

[Dylan16807]

A lot of circuitry? I would have thought a handful of (integrated) transistors could make it happen.

[wtallis]

Transistors that can handle a lot of current or voltage will need to be much larger than most of the logic transistors on a chip, so even though they may appear to be few in number on the schematic, they can add up to significant die area for a small part like a microcontroller.

[ska]

This is naive. There are tons of firmware changes that will render hardware unusable until the board is re-flashed (which you may not be able to do at that point), and even without moving parts the capability to damage components. Simple example, often firmware is the only thing that will stop your hardware from cooking itself if it is capable of doing so. Or if you mess with battery management you could conceivably get a fire. Or you mess with power distribution and send the wrong voltages, parts are fried. Or, etc. etc.

[wtallis]

You're really not trying hard to think of any possible answers, are you?

In most devices over a certain level of complexity, there's firmware involved in thermal management. Messing that up can easily lead to premature failure of the hardware, and in some cases very quick failure.

Even for a TV which may not have much of a thermal concern for its processor (though I wouldn't bet on it with today's smart TVs), you can still expect there to be some screen burn-in mitigation.

[matheusmoreira]

> You're really not trying hard to think of any possible answers, are you?

I asked a question because I don't know. I assumed you did. I'm trying to learn something.

[wtallis]

You're being passive-aggressively unimaginative and unwilling to seek out information for yourself, in a manner that is a common form of trolling. Even if trolling is not your intent, you should know that the idea of learning by asserting something wrong online and waiting to be corrected may make for a good joke but is not a polite and productive way to have online conversations.

[matheusmoreira]

I'm not being "passive-aggressively" anything. I asked a simple question. You're the one who started some firmware/software semantics argument instead of actually answering what I asked. I didn't assert anything either, other than that firmware is software. I continue to assert that now.

If you think I'm trolling, then simply don't reply. I've learned plenty from the other posts. I'd rather not create hardship for dang by continuing this thread.

[rcxdude]

Here's one moving part: speakers. It's becoming more common in the chase for good audio performance from small speakers to have a driver which can easily burn out the speakers, when given the wrong audio signal on normal volume. The firmware needs to actively model the power dissipation and temperature in the speaker and limit the signal if it could damage the speaker.

[xxpor]

Just tell the voltage regulator to output 12v instead of 3.3.

[rodgerd]

> I'm having trouble imagining how some TV could possibly be damaged by software

Modern OLEDs perform image manipulation to avoid burn-in. Your XDA Developers firmware is going to end up with your screen being garbage in a year.

Android firmware routinely allows processor overclocking, a great way to damage components in devices that have tight thermal requirements.

Those are two. Arguing that firmware can't damage the hardware that it controls shows a decided lack of imagination.

[brokenmachine]

One example is flash memory which can only do a certain number of writes (in the order of 10,000-100,000 writes).

You could have a firmware that saves everything to flash all the time and eventually causes the flash to become defective. It'd be easy to burn a flash out in less than a day.

[spc476]

There was an early 8-bit home computer where you could reprogram the video controller chip to drive the TV/display out of its operating range (timings/video frequencies, etc.) where left too long (how long? I don't know---I'm a software engineer, not hardware or electrical) could damage the TV/display.

Go back further, and you get to harddrive races, back when harddrives were washing machine sized devices, and if you get the heads going back and forth fast enough, they start shaking and could "walk" across the room. That doesn't sound like it's good for the harddrives.

[brokenmachine]

You could definitely brick it, in addition to all the stuff everyone else mentioned.