Originally Posted by blue_z
You've written a good problem report. But there's no reason to start guessing the cause, i.e. a "firmware bug". You're encountering a problem, a bug. For all you know, it could be a hardware bug. (Yes, I'm a FW engineer, and I hate to read bug reports that guess at the cause instead of just reporting symptoms, effective workarounds and other observations.)
FWIW (as a former software developer and tech writer), IMO it *is* a "software bug" for the software (including firmware, which is just software "carved in stone") to not trap/deal with hardware issues. (I don't limit this philosophy to hardware issues -- I extend it to all venues, most particularly *user* "issues" -- i.e., the software should be sufficiently bulletproof to ensure that inadventent keystrokes won't crash it.)
As to the case at hand, the classic example is the old TRS-80 kkey bbounce problem (eventually fixed by an OS upgrade (and with later models, I presume a firmware patch), initially addressed by a small driver loaded via cassette tape). It drove pretty much all users batty until they finally came out with the tiny pile of code to filter out the keybounces -- which *should* have been included in the firmware.
Yes, it was a "hardware problem" but it was equally a firmware problem (no way were they going to reengineer the entire machine to use bounceless keyswitches -- if such a thing existed; the firmware author(s) were presented with a machine that needed bootstrap/BIOS firmware, including a keyboard driver (the keyboard was scanned/mapped from the main address space -- a keyboard driver was integral to the system, and probably a bit of a PITA to code; including a debounce routine that would be evoked in the middle of what had to be an ugly kludge of an address scanner, in a non-multitasking environment, on a 1.77 MHz 8 bit computer... glad it wasn't me! )
Anyway, having hardware that includes misfeatures that are NOT compensated for by the firmware... is a firmware bug, IMO. The firmware developer(s) are hired to come up with code to turn the hardware into a usable product. Hardware always has "issues" and the software is the last line of defense, standing between the user and the iron.
Edited to add that I had NO connection with the TRS-80, other than as a *very* early adopter some thirty odd years ago. I don't want anyone to think I was involved with that project, since I wasn't!