13 Aug
2002
13 Aug
'02
12:21 p.m.
On Wed, 14 Aug 2002, Tony Duell wrote:
As Ben (?) said, the fun really starts when you have designed (and
constructed) both the hardware and the software yourself. Say you've
built a little microcontroller system and written the firmware for it.
You can have :
A hardware design problem (you used the wrong components)
A hardware construction problem (you wired to the wrong pin on the IC,
you shorted to connections together with a solder blob by mistake)
A software desgin problem (you used the wrong algorithm)
A software construction problem (you mis-coded that algorithm in the
machine code for the CPU you are using. A trivial example would be
assuming that an instruction affects CPU flags when, in fact, it doesn't,
or vice versa).
Actually it can get worse... because you may well have your own (maybe buggy
and always changing) software tools for creating or debugging the firmware...
Problems noted when trying to debug some FPGA based microcontroller firmware:
Firmware error (since I dont write the firmware I always blame this first ;-)
Bad FPGA hardware definition file (CPU or peripheral -- Stiffware error?)
Wrong hardware (Stiffware?) revision for firmware
CPU/assembler version mismatch
CPU/single stepper/dissasembler mismatch
I guess its time to have a CPU revision register in my CPU...
I would suspect software and hardware bugs take the
same magnitude
of time to find.It is when you have software interacating with
hardware the fun begins are you are now not sure what works.
Jerome Fine replies:
Fortunately I can't remember having that problem very often.
When I first started to program computers, I found it difficult
to find software bugs. While it is still difficult, I now realize that
hardware rarely fails. Although I have found a one or two bugs
You have to be able to isolate what's going on, and quickly, to have any
chance of fixing it. It's best to assume that nothing is correct at the
start, and then to verify everything a bit at a time.
Peter Wallace
(a) I once found a sticky bit - defined as a bit
which was always
ONE when it was supposed to be ONE, but sometimes a ONE
when it was supposed to be zero. The quick solution was to be
sure to place an instruction at that location which required that
the sticky bit be a ONE - that way, the program always worked.
Hardware Hacker's solution : Replace that darn RAM chip. It will 'bite'
you sometime. Other bits might fail too...
-tony