how to trace a microcontroller running it's app ?

[robb]

Thanks Chris for the help and ideas,
robb

Yes... Most will let you do this with a script.

Try uVision


I would agree.


The costs don't look small but if it is the only tool that will do the
job.....


The 80561 is far from obsolete. However is the OP is only going to do
this one 8051 project renting is a good idea.

OTOH if the OP wants to do a lot of 51 work buying a good one is a good
long term investment.

Costs depend on where you are and what you need. For 8051 the cables and
pods vary a lot depending on the target.

Not only the software but the facilities...
You need the ICE to be able to run at the bus speed of the target...
NOTE some 51's are *2, *3, *6 and *12 a standard 51.

You need trace & trace filtering, Also depending on how the trace
works the size of trace is important. Due to different methods a 2K
trace can be a effectively as big as an 8K trace

Trace should give C, ASM and raw (binary) trace.

conditional breakpoints etc

It goes without saying it should be non intrusive

You need both C and ASM debugging
system.

If you have a decent ICE you won't need the Logic Analyser.



And a lot of time and luck.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
/\/\/ [email protected] www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Thanks Chris for the help and ideas,
robb

 

[robb]

...snip...

To give you an idea of where to look... I used to have an old logic analyzer
made by Arium (which merged with American to become American-Arium) called
the ML4100C. It had plug in microprocessor pods for various
microcontrollers, including the 6502, the 8039 family, the 8051 family, etc.
I used it extensively for debugging microcontroller flow on several 8031
projects I had developed. It was indispensible. It showed exactly how the
program was executing and showed the instructions in assembly.

I've since then gotten rid of the logic analyzer (donated to our local
college) but it was sure nice when working on 8031 projects. I don't know
if you'd have any luck in trying to find such an animal anymore...

Good luck.
Dave

Thanks Dave,
lots of good info heer in usenet.

thanks again for info and reply,
robb

 

[TT_Man]

one treats the (02096f) in the first 3 bytes as a (long jump to
096F) where the other disassembles the (02096f) into something
else like this ...

0000 : 02 " " db 002H
;
0001 L0001:
0001 : 09 " " inc r1
;
0002 L0002:
0002 : 6F "o" xrl a,r7

02 09 5F is LJMP to 096F. dump the other disassembler.!

 

[Mark Borgerson]

02 09 5F is LJMP to 096F. dump the other disassembler.!

I ran into quite a number of problems of that sort in
APPLE II assembly code where whatever system
generated the code would intersperse defined constants
with the generated code. The disassembler would
try to disassemble string constants and debugging
data (such as function names, etc.) and would then
miss the first instruction of the next function.

Sometimes you may have to look at instructions
such as LJMP 096F and make sure that the
bytes at 096F really are executable code.

It's little things like that which make disassembling
and reverse engineering a non-trivial excercise.
Which is OK by me as it paid the bills for almost
half a year back in the '80s.


Mark Borgerson

 

[Paul E. Bennett]

So why don't you have the source code? (I know that there are sometimes
valid reasons for not having the source).

What do the motors drive? Are there any safety implications if you mess
around with the code?

Any ideas on how to do this? how possible ?

[%X]

It's not clear from your message what your goal is. Are you trying to
find out where performance bottlenecks are (profile), learn its
algorithms, or reverse-engineer the code?

There are a couple of things you can do cheaply. A few years ago we
built a "real-time debugger" that would let us peek into a running
system and see what it was doing. The trick was to connect one CPU as a
watchdog for the other. We set aside a few bytes of common RAM. We
inserted code in the CPU-under test to peek and poke a few registers
and memory locations during each major cycle. It could do this with
only a
minor effect on execution time. Then we programmed the test CPU to
peek and poke those same areas. We synchronized the two via enable
pins. Finally, we wrote a hex monitor for the test system that could
display the current values in RAM. This program only needed to run at
operator speeds.

At least that method is non-intrusive and can give you access via a
chip-clip over the processor part. However, that only gives you a view
of what happens on the chip pins. You may still be blind on what is
going on inside.

A good dis-assembly of the code so that you can at least see the
structure of the code and data elements in the ROM might give you what
you need to re-construct it. You will have to work out and add your own
comments then you can re-build the ROM from scratch and have a much
better view when you insert the break-points. You could even consider a
change of implementation language and have much better tools.

--
********************************************************************
Paul E. Bennett...............<email://[email protected]>
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************