Dec TU-56 Question

From: Peter C. Wallace <pcw_at_mesanet.com>
Date: Tue Aug 13 19:21:00 2002

On Wed, 14 Aug 2002, Tony Duell wrote:

> > > 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
>
> 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...



>
> 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.
>
> > (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
>
>

Peter Wallace
Received on Tue Aug 13 2002 - 19:21:00 BST