> If you are easily able to change the firmware, you are easily able to destroy the hardware
How could custom software destroy a phone, a computer, a TV, a printer?
> if that's under warranty
Just void it.
How could custom software destroy a phone, a computer, a TV, a printer?
> if that's under warranty
Just void it.
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.
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 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.
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.
I asked a question because I don't know. I assumed you did. I'm trying to learn something.
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.
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.
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.
The extra current is a physical thing and you need more material to temporarily withstand it, and more circuit to detect and control it. Since it's an uncontrolled switching event, it'll probably ring unless you add even more components to absorb and control that. Then that could exceed the physical limits and trigger a parasitic circuit that doesn't have an off switch, so you need yet another circuit to detect and shut it off somewhere else.
It can be a lot of work for the board designer to make it reliable and compatible, assuming the other chip it's talking to can also handle the extra current. It's cheaper and more reliable to type GPIO1DIR=OUT or whatever. Sort of like when you drive a car, it's easier to choose to drive in the correct lane than it is for the car to enforce it on you and protect you if you do it anyway.
Supposedly most of the chips can already temporarily withstand extra current. But the point of a current-limiting circuit is that you don't have extra.
> uncontrolled switching event
I'm not suggesting turning it off entirely, unless that's much much easier.
> it'll probably ring unless you add even more components to absorb and control that
If it fluctuates some when overloaded, that still sounds better than frying itself. But I'd expect an integrated implementation to keep pretty tight bounds.
> that could exceed the physical limits and trigger a parasitic circuit
What physical limits? You've lost me at this point.
> It can be a lot of work for the board designer
I was suggesting building it into the chip.
Digital CMOS is triggered to switch between fully on and fully off. You can't really hold it in between. If you do, you get undefined behavior.
The ringing can have an initial spike that fries stuff.
CMOS can break down and the current will flow through a different path away from the gate where the gate can't turn it off. Called latch-up.
It is in the chip. The protection circuit can add a lot of parasitic elements to the pin interface that you have to account for when you design the board.
Controlling the voltage put into the output transistor shouldn't use much power or output much heat, should it? The output transistor will heat up based on voltage loss, but it needs to be able to handle a notable amount of that even when it's not shorted.
> Digital CMOS is triggered to switch between fully on and fully off. You can't really hold it in between. If you do, you get undefined behavior.
The pins are already tri-state. The logic to output +V, or output 0V, or neither already exists. So it won't fight itself.
> The ringing can have an initial spike that fries stuff.
How can you make a transistor's output spike higher than it does with the existing digital drive method?
Yes but I'm missing why they would need significant amounts of space or power compared to the big transistor that's actually dealing with the current.
> Digital CMOS is bi-state and the pin is tri-state, therefore you can conclude that there are additional components involved to achieve the third state.
Yeah, so less to add and less to worry about compensating for because it's already handled.
> Spiking can be caused by suddenly shutting off current through a parasitic inductance because it sort of has inertia and can't stop immediately.
It already abruptly turns on and off. How does an extra trigger condition make that worse?
Or in other words, how are we not already in the worst case, with nowhere to go but up? (Since if we're just controlling the transistor better we won't be adding any more inductance than the pin already has.)
It's not already handled because you still need a circuit that detects the condition and switches to tri-state, if that's even how it's implemented.
Ringing and spikes come from electrical mismatch. If the protection changes the electrical properties of the pin, it may have to do more work to damp out the new mismatch. "Abrupt" isn't a single thing with a universal solution.
We're not just controlling transistors, but also sensing, shunting, clamping, damping, etc. And we're starting from the best case so we have nowhere to go but down.
You'll have to look up the rest yourself.
It should always be tri state. Never allow the positive and negative output transistors to get power at the same time. If that particular detail wasn't already implemented, it'll take like two logic gates more. Which is absolutely nothing compared to the rest of the chip.
And again, don't change the electrical properties! Tap like a microamp for monitoring, on a pin that outputs milliamps.
It doesn't matter that there is no universal solution to "abrupt" because we already have an acceptable setup and it's not changing.
Sensing can be done with no real impact on output characteristics. Additional shunting and clamping is not necessary. If the damping only happens by controlling the output transitor, then it's no different from how the circuit already works.
And no we're not starting in the best case. We're starting with a transistor where the design goal was to have as fast a slew as feasible. If it already doesn't overshoot dangerously, then using the same or slower slew shouldn't be hard to avoid overshoot, all else equal.
Most of your objections come down to "if you change X you might cause problems" when I'm saying not to change X.
Down below the digital level, you can't isolate decisions from each other and nothing is free.
I'm using tri-state to mean it has three distinct states. The output transistors are not sharing a control wire to make them one on, one off. If that's wrong use, I'm sorry.
The point I'm making is that it's easy to make it so the output transistors don't fight, even if the one that's enabled gets a halfsies voltage, because the other one won't also get a halfsies voltage, it will get a pure digital off.
> Damping dissipates heat, so damping by controlling the output transistor requires a bigger output transistor. Damping the output transistor also changes the electrical characteristics of the pin.
I'm assuming it's already kind of heat resistant because it only sometimes fails when shorted with no limiter at all. And if you damp it enough you won't make much heat. But fine, let's ignore that. You already brought up just turning it off at a certain point. If that's what's needed, so be it, because that won't change the characteristics.
No magic needed to keep the characteristics the same if you're just turning it off the way it normally turns off.
But I still don't understand how a transistor with an input that damps it is supposed to cause voltage spikes in excess of the same transistor with an input that doesn't damp it and always switches with maximum aggression, with only the control logic changing.
If damping makes heat, how can damping it enough make less heat? Why are you assuming that it's heat resistant if this is the level where you design the amount of heat resistance it has? Who did that work? Nobody, you have to do it yourself.
There is no control logic. It's analog. Logic is digital. Digital doesn't exist until we're done.
Sorry, but I've done all I can. Good luck in your search.
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.
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.
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.
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.