how to trace a microcontroller running it's app ?

address

on the

board without

servo

time with

this with

to sight

oops my reply went too early i had not finished so this is just continue of previos.

ok, i believe it. i thought maybe step through the real program in PAUMON with real feedback

*BUT*

my brain lapse/over active imagination/etc I see your point, the paulmonis not going to be doing any translation for me and certainly not clearing a path to all the I/O , i guess my hopes for paulmon (monitor) were too high

run

have the

:( alas another project i am working on

have built

*will* be

which company

well i am trying to do this hobby style so probably will not progress to that point sorry to put a wrench in your potential windfall earnibngs :)

thanks for help and ideas Ian, robb

it's

"Paulmon"

and

to

program

run

require you to

will be a great

used. You

to various

parameters for

instructions.This will

instructions in the

letters. i.e

output.

the keys are

discover this....

basic OP codes

Thanks for the help and reply TT_Man,

I've started a bit down the path you suggest already. I printed out data sheets for all the onboard ICs for quick reference to what the inputs and outputs should look like. i started on creating a schematic/circuit diagram for the micro-board for understanding and easy lookup of interconnections.

i have dis-asembled the ROM code with a dis52 from the 8052 web site and i also used another dasmx130 that someone suggested but i get two different dis-assembles ?

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

so that can not be a good sign , and leads to confusion so i suppose i will need to hand dis-asemble aways and confirm which dis-assembler is more accurate.

Looking at some used books on 8051 by MacKenzie and others

Thanks again for advice TT_MAN, robb

Thanks Chris for the help and ideas, robb

run

you'll need a

do the

essentially

to do

is a good

cables and

target...

trace

a 2K

system.

E.E., with

analytical mind

Thanks Chris for the help and ideas, robb

it's

purpose

the

execution on the

preferably

in-circuit

logic analyzer

American-Arium) called

family, etc.

several 8031

exactly how the

our local

don't know

anymore...

Thanks Dave, lots of good info heer in usenet.

thanks again for info and reply, robb

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

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.

End result: We could watch any part of the program, by looking at data on successive interrupt cycles.

Come to think of it, this is exactly what Heathkit built into their H-8 computer, ca. 1978. At a 60 Hz interrupt rate, they sent selected CPU registers and RAM locations to a front panel hex display, and accepted hex inputs from a keyboard. If you only recreate the Heathkit electronics (which were minimal), you won't be far off the mark.

For profiling, there's also a way. It's called stochastic profiling. Basically, it interrupts the running program and finds out where the program counter is. Then you can draw a histogram of the time spent in each section of the program, and thereby find bottleneck spots.

Hope this helps.

Jack

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?

[%X]

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...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-811095
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************