Debugging tools (long, philosophical)

[Roger Heflin]

On Fri, 5 Mar 1999 DAVE_HEMPSTEAD at HP-Andover-om3.om.hp.com wrote:

> Hi,
>    Well I've watched the debates over tools and ram emulators, etc, go on for 
> weeks, and I've finally got to dive in.  So here goes......
> 
>    Before I enter the debate about what features go into a ram emulator, I think
> we should agree upon what problems we are trying to solve.  Different tools 
> solve different problems.
>    I'll start off with a list of some of the problems I'd like to solve, and 
> then propose some tools which might help me solve them.
>    One other assumption for me:  I want all my tools to be cheap to buy/build. 
> (I admit, I'm cheap).
> 
>    When you are looking at tools, there are many parameters to help you select 
> the right one (and everyone's parameters are different).  For example, price is 
> one parameter.  Others are:  complexity to build, invasiveness, ruggedness, 
> size, reliability, etc.
> 
> 
> 1.  Problem:  I don't know what my ECM is doing 'right now'.  I want to  know 
> what the last values it output were, which ones are changing and how often they 
> are changing.
> 

I have been using a scan tool for this.  Diacom is giving me about 7
frames per second of output, from that I was able to tell if the code
I was adding was working correct. (it was not quite, and a 93 Z28 ECM
takes about 1/5 of a second to reboot, and the engine lurches).  It
would have been useful when I was crashing it if I had at least an
eprom address access list, then I would have more quickly found the
code where the mistake was, the mistake was pretty obvious though, a
hex 0x00 is the "test" command, and it is a bad command to run while
not in test mode, I ment to have put in a NOP (0x01),
Since all of the modifications I was doing were related to parameters
that were output on the ALDL port, I was able to see if this were
working correctly.   Probably the ALDL device you have can do similar
jobs.   You could also do something weird and replace the ALDL
routine, and wire in something higheer speed someplace unused in the
address space and dump that to an external computer.  The ALDL routine
looks like it uses at least 30-40 instructions, and at 8192 bps, would
have to be being hit about 1024 times per second, so with hardware
added in you could pretty easily dump more parameters at a higher
rate.   This may affect what is happening, preferralby not though.

What I see that is really a problem, is you cannot snoop the ram,
since I believe it is internal to the chip.  If it were external you
would be able to snoop it with a logic analyzer.

>     Any tool to solve this problem will not affect what is happening, it will 
> just watch it.  Therefore, this tool should be usable at any time (engine off, 
> running, etc).  
> 
>     One possible tool:  One way to solve this is to use a logic analyzer either 
> on the outputs of interest, or one on the processor (to see them all).  Note 
> that I'd need a good understanding of how the processor's addresses map to the 
> actual outputs for the processor-logic-analyzer to work.
>     Other possible tools are simple meters, oscilloscopes, led indicators, etc.
>     As for me, I want a cheap logic analyzer.

See above to see the problem with the logic analyzer and the internal
ram.
> 
> 2.  Problem:  I want to change what my ECM will do (next time it is run).
> 
>     For this problem, we want to change behavior, but not while the ECM is 
> running.  Once it is changed, then we can 'let-er-rip' and use tool #1 to see 
> the results.
> 
>     One possible tool:  A prom programmer and sockets in the PCM.  
>     Another possible tool:  A rom emulator.  This would need a way to download 
> the new data (while engine is off) from somewhere else (like from a PC or other 
> rom's), and then when the ECM is turned on, act like a rom.
>     Another possible tool:  Software which communicates with the ECM which 
> downloads new values into the existing rom (would only work for flash, or eeprom
> if the programming voltages were available).
>     Another possible tool:  Replace the rom with battery backed up ram, and make
> sure that the battery can never run down.  Then all you need is a tool to write 
> to ram.

I have been doing this with a eprom, it would be better to be using a
emulator that can be changed faster, but I am not sure that botherss
me that much.    The only problem wiith the flash rom and eeproms is
that on the f-body list there have been accidents that required the
computer to be removed and sent elsewhere to be reprogrammed.   At
least if you have the flash or eeprom socketed you can fix that with
an external programmer.

 > 
> 3.  Problem:  I want to see what my ECM is doing 'right now' and change it.  
> This is basically a superset of #1 and #2.  
> 
>     This is the toughest problem to solve, since it allows you to be invasive, 
> yet you want to keep the processor 'doing its job'.  You'd want to be able to 
> use this tool while the engine is running.
> 
>     One possible tool:  A processor emulator, which plugs into the cpu slot, and
> has its own internal memory space that you can download into.  It lets you 
> change memory locations (and therefore outputs).
>     Another possible tool:  A rom emulator (built out of ram's) that you can 
> change while the processor is running.  Presumably you would change the memory 
> locations via a PC and you interleave your access memory cycles with the ECM's 
> processor.  For this solution, you probably need some software in the memory 
> space which makes the ECM to set individual outputs to values located in memory 
> (that you can download), since you are unable to write to the output registers 
> directly.
> 
The really sick way to do some of the would be to make a program that
emulated the car computer (and the cpu in it), including you being
able to set all inputs and see the results.   But everything would
need to work exactly the same.

					Roger