Sigmo
Second Officer
United States
Offline
|
This is a good thread.
I'm sure that the advice to refresh the firmware is largely offered because it's part of a canned menu of advice or even an automated response to pretty much anything and everything. When I have trouble with my internet provider's service, even if I can see the cable dangling from the telephone pole behind my house, I KNOW I'm going to be asked to reboot the modem. That's just the way these things go. That first line of defense between us and an actual technician or engineer will be someone reading from a script, or some automated system.
Sometimes you're surprised, though, and get someone with some experience, but it's rare.
Anyhow, with that being said, as I've been pondering this a bit, I think there may actually be some merit to doing the obligatory refresh of the firmware.
Hopefully not because the firmware got installed badly the first time (one would hope that there are checksums and error correction being employed that should prevent bad data from being installed... hopefully, I say. ;)
But I think back to when microprocessors were first being used. Back in the mid-late 1970s when the company where I worked was first designing, building, selling, installing, and, of course, troubleshooting telemetry systems based on microprocessors, you would be amazed at how many times we'd have a customer call with a problem and we'd ask them to switch the system off, wait a minute or two, and switch it back on. And then tell us if that "fixed" it. And you'd be even more amazed at what a high percentage of the time that did, indeed, "fix" the system.
The old joke about doctors back then was that they'd say: "Take an aspirin and call me in the morning." Ours was: "Cycle power and call me in the morning."
And the reasons for this working were several. First, RAM could (and can) be corrupted by alpha particle decay (because growing the silicon ingots from which wafers are sliced cannot completely eliminate all radioactive isotope contamination within the bulk of the material). An alpha has a powerful charge capable of changing the charge on one of the tiny data storage capacitors in the memory itself. This also can happen from cosmic ray interaction or even terrestrial gamma. The fact is that "soft errors" can occur from a number of sources.
Modern devices have more error detection and correction going on, but soft errors can occur. These problems are far less likely now than they were back then, but (stuff) still happens!
And here's the thing: Back in those days, you could cycle power on one of our microprorcessor systems, and when the device powered up, our power-on-reset system would trigger a "hard reset". And that meant that the processor would execute a section of code that was designed to set everything up again, clear any scratchpad memory, initialize all of the variables that we wanted to have initialized, etc., and only then, actually start execution of the operating program(s). So a power cycle performed a lot of what we called "housekeeping routines" and also what was called back then "Garbage Collection". Other things could trigger garbage collection, but a power cycle did the ultimate in all of this.
Now, think about the Mini and the RC.
There is no "power switch" on either. We have a momentary-contact pushbutton. And we know that these buttons serve mulitple functions depending on the pattern of presses we give it. So we know that these "power buttons" are really nothing more than an input point for the I/O of one of the processors in the drone or RC. And we know that both are already running all of the time that they have a battery installed. Either might be in a low-power mode, but it's certainly not "off". It's executing code, and at the least, monitoring the status of that "power" button.
Neither the Mini nor the RC can be "power cycled" by these buttons.
In the drone, we can pull the battery. But in the RC, we cannot. There's no way for the user to do any kind of reboot of the RC. Unless, we do a firmware reload, perhaps.
And even in the drone, there are certainly areas of nonvolatile RAM and flash areas that are not wiped when we swap batteries.
With a cell phone, we might be asked to do a full power down or restart. If that doesn't help, maybe clear the cache. If that doesn't get it, maybe a more thorough process of clearing even more memory. And finally, if that doesn't get it, back everything up and do a factory reset.
We don't have any real ways to do any of those things on the RC, or even the Mini from their "power buttons".
So maybe doing a re-installation of the firmware triggers the performance of some of these "reboots" and "garbage collection" or clearing of the caches, etc., that we have no other way to do. And when we're asked to reflash the firmware, it's really their only way of asking us to "cycle power and call me in the morning".
It's interesting to watch the Mini when you're reinstalling its firmware. It spasms and makes sounds a number of times through the process. There's a lot going on that I don't understand. Who knows what all gets done?
|
|