Jack Crenshaw wrote:

> robb wrote:
>> I have a (8051) micro-controller that i would like to trace it's
>> runtime program to understand how the program works for purpose
>> of potentialy modifying code. (The only info of program is the
>> program binary copied off ROM )

So why don't you have the source code? (I know that there are sometimes
valid reasons for not having the source).
 
>> The micro-controller consists of  (usuall stuff):
>> ---------------------------------------
>>> Siemens 8031, ROM, SRAM
>>> servo motors (+ driver ICs)
>>> simple user 16 char (14 seg) interactive display
>>> grid of buttons (24)

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

robb wrote:
> I have a (8051) micro-controller that i would like to trace it's
> runtime program to understand how the program works for purpose
> of potentialy modifying code. (The only info of program is the
> program binary copied off ROM )
> 
> The micro-controller consists of  (usuall stuff):
> ---------------------------------------
>> Siemens 8031, ROM, SRAM
>> servo motors (+ driver ICs)
>> simple user 16 char (14 seg) interactive display
>> grid of buttons (24)
> 
> Any ideas on how to do this?  how possible ?
> 
> I have a PJRC 8051 Rev.4 development board that runs "Paulmon"
> which allows you to load your program to some offset in RAM and
> step through it. (i really want to see the I/O as it runs
> though)
> 
> My idea/thought at first was to maybe connect the PJRC  board to
> the MCU socket of the microcontroller board and trace the program
> ??
> 
> What i have tried is load in a simulator like (EdSim51) to run
> and determine what program does but i would need to some how
> simulate all the devices (input) ?
> 
> any help and ideas greatly appreciated,
> robb
> 

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

In article <vOMij.47141$745.31820@newsfe1-win.ntli.net>, 
Someone@ntlworld.com says...
> >
> > 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.! 
> 
> 
> 
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

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

"starfire" <starfire151@cableone.net> wrote in message
news:13ohrc4u6lqv5b@news.supernews.com...
>
> "Ian Malcolm" <valid.address.in.signature@invalid.invalid>
wrote in message
> news:fm9gru$1qj$1@inews.gazeta.pl...
> > robb wrote:
> >
> >> I have a (8051) micro-controller that i would like to trace
it's
> >> runtime program to understand how the program works for
purpose
> >> of potentialy modifying code. (The only info of program is
the
> >> program binary copied off ROM )
> >>
> >> The micro-controller consists of  (usuall stuff):
> >> ---------------------------------------
> >>
> >>>Siemens 8031, ROM, SRAM
> >>>servo motors (+ driver ICs)
> >>>simple user 16 char (14 seg) interactive display
> >>>grid of buttons (24)
> >>
> >>
> >> Any ideas on how to do this?  how possible ?
> > The *ONLY* practical ways of tracing the *actual* program
execution on the
> > *actual* hardware are either with a high end logic analyser
preferably
> > with support for displaying 8051 instructions or with an
in-circuit
> > emulator. ...
> ...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

Thanks Chris for the help and ideas,
robb

"Chris H" <chris@phaedsys.org> wrote in message
news:aljMVJLc4giHFAG2@phaedsys.demon.co.uk...
> In message <nWmij.28537$ov2.15767@newsfe5-win.ntli.net>, TT_Man
> <Someone@ntlworld.com> writes
> >> What i have tried is load in a simulator like (EdSim51) to
run
> >> and determine what program does but i would need to some how
> >> simulate all the devices (input) ?
>
> Yes... Most will let you do this with a script.
>
> Try uVision
>
> >> any help and ideas greatly appreciated,
> >> robb
> >
> >Hi, robb.  To accomplish what you need for an 8031/8051,
you'll need a
> >real-time in-circuit emulator.
>
> I would agree.
>
> > This will not be inexpensive.
>
> The costs don't look small but if it is the only tool that will
do the
> job.....
>
> > But
> >since your need is project-specific and the processor is
essentially
> >obsolete, I'd recommend renting one.
>
> 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.
>
> > The ICE should cost less than
> Costs depend on where you are and what you need. For 8051 the
cables and
> pods vary a lot depending on the target.
>
> >  Make sure your rental includes the software you
> >need to do the job.
> 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
>
> > You're also going to need a logic analyzer and a
> >digital storage scope to observe operation of the servo
system.
>
> If you have a decent ICE you won't need the Logic Analyser.
>
>
> >This one would be a tough go, even for an embedded controls
E.E., with
> >the real-time control of a servo system.  Give it up, robb.
> >
> >Good luck
> >Chris
> >
> >You don't need all that stuff, just a logical, inquisitive
analytical mind
> >:) Which it seems you have!
>
> And a lot of time and luck.
>
> -- 
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
> \/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
> /\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
> \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
>
Thanks Chris for the help and ideas,
robb

"TT_Man" <Someone@ntlworld.com> wrote in message
news:f23ij.151$WJ.81@newsfe4-win.ntli.net...
>
> "robb" <some@where.on.net> wrote in message
> news:13og7rtskr36f6@corp.supernews.com...
> >I have a (8051) micro-controller that i would like to trace
it's
> >
> > I have a PJRC 8051 Rev.4 development board that runs
"Paulmon"
> > which allows you to load your program to some offset in RAM
and
> > step through it. (i really want to see the I/O as it runs
> > though)
> >
> > My idea/thought at first was to maybe connect the PJRC  board
to
> > the MCU socket of the microcontroller board and trace the
program
> > ??
> >
> > What i have tried is load in a simulator like (EdSim51) to
run
> > and determine what program does but i would need to some how
> > simulate all the devices (input) ?
> >
> > any help and ideas greatly appreciated,
> > robb
> >
> I have done lots of this........
> Step1. Build a circuit diagram, one way or another. This may
require you to
> remove some components.Having the pinouts of the chips used
will be a great
> help, especially the 8031.
> Step 2 disassemble the rom. This will give you all the op codes
used. You
> will have to split the code into various blocks:-
> Jump Vectors- in the first 20 or so locations- these will point
to various
> routines....
> Restart/power up/initialisation
> Rx/Tx uart routines ( maybe /maybe not used)
> Timer interrupt routines
> Int0/Int1 hardware vector routines.
> Etc.
> At the restart vector, you will find all the system setup
parameters for
> timers/uarts/baudrates/real time clock etc.
> From the disassembly draw a line under ALL RET/RETI
instructions.This will
> section the code into 'blocks.
> try and associate blocks with functions, i.e stepper
> drive/buttons/uarts/display by making reference to PORT
instructions in the
> listing.
> Give the start of routines a 'real name' instead of numbers or
letters. i.e
> UartTx/UartRx/Timer 1 setup/timer2 setup/Kbrd Scan/Display
output.
> You may find the kbrd/display is an integrated solution, i.e
the keys are
> linked to the display. The circuit diagram will help you
discover this....
> You will need to read up on how the 8051 works and what the
basic OP codes
> do.
>
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

"Ian Malcolm" <valid.address.in.signature@invalid.invalid> wrote
in message news:fm9gru$1qj$1@inews.gazeta.pl...
> NO ****ING WAY, You would need to 1. make sure there are no IO
address
> conflicts between the two boards, 2. disconnect all RAM and ROM
on the
> target board, 3. Relocate the code to run on the PJRC 8051
board without
> clashing with the monitor, and 4. run it without frying the
servo
> drivers or the servos. 5. get everything *exactly* right first
time with
> no accidents with 32V supplies etc.  I wouldn't like to tackle
this with
> a processor I am *extremely* fammiliar with. (I used to be able
to sight
> read the raw HEX for *most* of the instruction set of a Z80)
>

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

> >
> > What i have tried is load in a simulator like (EdSim51) to
run
> > and determine what program does but i would need to some how
> > simulate all the devices (input) ?
>
> Yes, there *are* simulators that support virtual I/O. Do you
have the
> circuit diagram?
>

:( alas another project i am working on

> >
> > any help and ideas greatly appreciated,
> > robb
> >
>
> Yes - Put it aside for a year while you learn 8051.  When you
have built
> your own development board and coded your own monitor you
*will* be
> ready for this.  Meanwhile, if you *must* procede, tell us
which company
> you get your components from so we can buy shares in a company
> experiencing a *significant* upturn in sales!
>
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

On Jan 12, 2:03=EF=BF=BDam, "robb" <s...@where.on.net> wrote:
> I have a (8051) micro-controller that i would like to trace it's
> runtime program to understand how the program works for purpose
> of potentialy modifying code. (The only info of program is the
> program binary copied off ROM )
>
> The micro-controller consists of =EF=BF=BD(usuall stuff):
> ---------------------------------------
>
> > Siemens 8031, ROM, SRAM
> > servo motors (+ driver ICs)
> > simple user 16 char (14 seg) interactive display
> > grid of buttons (24)
>
> Any ideas on how to do this? =EF=BF=BDhow possible ?
>
> I have a PJRC 8051 Rev.4 development board that runs "Paulmon"
> which allows you to load your program to some offset in RAM and
> step through it. (i really want to see the I/O as it runs
> though)
>
> My idea/thought at first was to maybe connect the PJRC =EF=BF=BDboard to
> the MCU socket of the microcontroller board and trace the program
> ??
>
> What i have tried is load in a simulator like (EdSim51) to run
> and determine what program does but i would need to some how
> simulate all the devices (input) ?
>
> any help and ideas greatly appreciated,
> robb

You need a logic analiser, loads of cheap ones on ebay. Once you
capture  a program loop you can load it onto your simulator and step
through it, if its function is not obvious. Program the analiser to
ignore that loop and repeat untill you have them all. The whole
process is suprisingly easy if your source is not too big.

"Ian Malcolm" <valid.address.in.signature@invalid.invalid> wrote
in message news:fm9gru$1qj$1@inews.gazeta.pl...
> robb wrote:
>
> > I have a (8051) micro-controller that i would like to trace
it's
> > runtime program to understand how the program works for
purpose
> > of potentialy modifying code. (The only info of program is
the
> > program binary copied off ROM )
> >
[trim]
> > Any ideas on how to do this?  how possible ?
>
> The *ONLY* practical ways of tracing the *actual* program
execution on
> the *actual* hardware are either with a high end logic analyser
> preferably with support for displaying 8051 instructions or
with an
> in-circuit emulator. Google 8051 ICE or 8051 JTAG for lots of
links to
> commercial products. CAUTION a board with servomotors *may*
need a real
> time emulator to do usefull debugging and that wil be
$$expensive$$.
> You are wasting your time if you haven't mapped out the IO
decoding and
> haven't allready got a printout of the dissasembly of the rom
marked up
> with your best guess as to which routine does what, data areas
etc. If
> you cant sight read a dissasembaly of the program and
understand it you
> are SOL untill you've put in some hard time with your 8051
development
> board.  Expect to kill one tree for every program you reverse
engineer
> (piles of paper!!) ;-)
>

Thanks Ian,
Doesn't sound easy.

so it is dis-assemble code , print, familiarize with 8051
instruction set, map and decode the I/O , estimate
function/routine purpose.

and what will i do with the other 23 hours of that day :D.

>
> >
> > I have a PJRC 8051 Rev.4 development board that runs
"Paulmon"
> > which allows you to load your program to some offset in RAM
and
> > step through it. (i really want to see the I/O as it runs
> > though)
> >
> > My idea/thought at first was to maybe connect the PJRC  board
to
> > the MCU socket of the microcontroller board and trace the
program
> > ??
>
> NO ****ING WAY, You would need to 1. make sure there are no IO
address
> conflicts between the two boards, 2. disconnect all RAM and ROM
on the
> target board, 3. Relocate the code to run on the PJRC 8051
board without
> clashing with the monitor, and 4. run it without frying the
servo
> drivers or the servos. 5. get everything *exactly* right first
time with
> no accidents with 32V supplies etc.  I wouldn't like to tackle
this with
> a processor I am *extremely* fammiliar with. (I used to be able
to sight
> read the raw HEX for *most* of the instruction set of a Z80)
>

ok, i believe it.
i had noticed that the PJRC dev board had a row of pins (access
points) to all the MCU pins and i thought i might be able to just
connect up the relevant pins, load program into dev board, and
then step through the real program in PAUMON  with real feedback

> >
> > What i have tried is load in a simulator like (EdSim51) to
run
> > and determine what program does but i would need to some how
> > simulate all the devices (input) ?
>
> Yes, there *are* simulators that support virtual I/O. Do you
have the
> circuit diagram?
>
> >
> > any help and ideas greatly appreciated,
> > robb
> >
> Yes - Put it aside for a year while you learn 8051.  When you
have built
> your own development board and coded your own monitor you
*will* be
> ready for this.  Meanwhile, if you *must* procede, tell us
which company
> you get your components from so we can buy shares in a company
> experiencing a *significant* upturn in sales!
>
> -- 
> Ian Malcolm.   London, ENGLAND.  (NEWSGROUP REPLY PREFERRED)
> ianm[at]the[dash]malcolms[dot]freeserve[dot]co[dot]uk
> [at]=@, [dash]=- & [dot]=. *Warning* HTML & >32K emails -->
NUL: