A lot of consumer electronics, like phones and laptops, are powered via USB-C these days. It is capable of supplying a wide range of voltages, and the device will negotiate a voltage with the charger. This requires a PD controller on both sides - which is configured via firmware. Imagine your device was designed to charge at 9V, but custom firmware makes it request 48V instead.
Display panels these days use firmware to drive the panel itself. Instead of a pixel simply being on or off, it is driven with a voltage waveform which specifies how long which voltage should be applied and in what order. This allows things like "overdrive" to reach a faster response time. I would not be surprised if a corrupt waveform would cause physical damage, as the pixel would be driven way beyond its design specifications.
An inkjet printer could have the print head move all the way to one side and keep driving the motor. If the motor driver does not have proper temperature protection, it could result in the printer catching fire. A laser printer could have the firmware turn on the fuser's heating element until it catches fire.
> 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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
The firmware is what stops you frying components. A good example is that MacOS has software which prevents the speakers from being over driven resulting in physical damage. There are other problematic things like overwriting flash memory which might result in the device not functioning properly.
Most of the time it would be extremely difficult to work out if the user caused the damage or if there was a bug or manufacturing fault. So they just give you a replacement anyway. It would be possible to create extra checks and void flags to try to detect this but that's just extra cost to the product for a feature almost no one cares about.
Another example: Your CPU has software that throttles its performance as it heats up, and eventually shuts it down. Remove that safety with custom firmware and you can make it overheat. Same thing goes for hard drives, SSDs, network interface cards, and so on.
I'm not sure vendors can void warranties in all countries. If you make a product that advertises itself supporting custom firmwares, then your hardware should be capabale of doing so would likely be how it is viewed in my country.
Just one example: the firmware for some piece of hardware could control the DC biasing of the device. Set the bias incorrectly and now you're drawing more current than is safe for the hardware and drastically reduce the lifetime.
Display panels these days use firmware to drive the panel itself. Instead of a pixel simply being on or off, it is driven with a voltage waveform which specifies how long which voltage should be applied and in what order. This allows things like "overdrive" to reach a faster response time. I would not be surprised if a corrupt waveform would cause physical damage, as the pixel would be driven way beyond its design specifications.
An inkjet printer could have the print head move all the way to one side and keep driving the motor. If the motor driver does not have proper temperature protection, it could result in the printer catching fire. A laser printer could have the firmware turn on the fuser's heating element until it catches fire.