Industrial application for HC11

"Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
news:20041105.79B3220.8244@mojaveg.iwvisp.com...
> "Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
>
> > As for the assembly code, begin by trying to identify the blocking
> > structure of the code. ie:- use a highlighter pen to show where bits of
> > sub-routines begin and end. Be prepared to have several goes at this bit
as
> > you will not necessarily get it right tghe first time through. This can
> > probably bnest be accomplished from following the reset vector jumps and
> > walking through the code bit by bit.
>
> You can automate this to a very high degree by building
> a symbol table and noting which addresses are referenced
> by JSR/BSR (procedures) and which are referenced by the
> other instructions (data).  Data areas greater than two
> bytes on the 68XX family tend to be character string
> constants and can be tested for content to distinguish
> between that and address constants with a high degree of
> success.  [There won't be much character string data in
> an ECU.]

Thanks for the suggestions guys, but I am pretty experienced
at reverse engineering by dis-assembly. I have already re-built
the disassembly as an asm file, identified all the data areas and
tables, and can actually re-assemble the code to give a byte-by-byte
comparison with the eprom! Using the 2500AD X68C11 assembler
allows me to generate a cross-reference listing which is very useful
as it show who calls who and how often!

However, as you probably well know, making serious sense of 11,000+
lines of code still requires a BIG effort, particularly as there are
hundreds of boolean type flags!

I would be prepared to put that effort in but the main problem
is identifying the cpu pins (84 pin plcc package). The cpu is
a 'sc' part, with some extra hardware which is difficult to identify
without a datasheet or pinout. There are extra port addresses which
go beyond those normally found in a hc11 core, and also a couple
of extra interrupt vectors below the usual range!

Even more difficult is identifying some unusual ic packages that
have custom Denso markings and odd dil packages. I suspect
these are 'surge-suppression' type components but you still have
to find what are inputs and outputs in order to identify what
the hardware is connected to - oh well, always a good project
when I retire......

The HC11 has been shipping since the early 80s, so you can bet that in the last
25 years some of those millions of hc11s have done something significant. I
heard that  this was a popular cpu in early cells phones... probably
motorola.... there is moto app note on how to use 128k ram as 32k pages with
hc11. Ford uses intel micros, gm uses moto micros... I heard this was because
ford bought all the intel micros they could make, and vice versa. Nowadays I
bet there are 16 bit and 32 micros in car computers, but the hc11 had its
day......

BobGardner wrote:

> The HC11 has been shipping since the early 80s, so you can bet that in the last
> 25 years some of those millions of hc11s have done something significant. I
> heard that  this was a popular cpu in early cells phones... probably
> motorola.... there is moto app note on how to use 128k ram as 32k pages with
> hc11. Ford uses intel micros, gm uses moto micros... I heard this was because
> ford bought all the intel micros they could make, and vice versa. Nowadays I
> bet there are 16 bit and 32 micros in car computers, but the hc11 had its
> day......
Depends...the more bits in a 'word', the more memory is needed, which 
means more real estate,...this ups the cost.  Altho with memory prices 
dropping this may not be as much of an issue. But if one is producing 1 
million of them, cost scales appropriately.  Another forcing factor is 
number of processors - as a data point, current 'high end' autos (i.e. 
BMW, Mercedes, Cad, etc) have anywhere from 50-70 micros in them.  One 
philosophy is to have a micro for each function, and bus them together 
if they need to communicate.  Another is throw a big processor at it and 
have it do everything.  Depends what the mfg is trying to max/minimize 
and the overall architecture to achieve it.
John

This is probbaly either an M, N or PH8 part. It isn't likely to be a P 
or K, or G. I still have most of these around. I definitely have 2 
windowed PH8 parts. These were all IIRC 84 pin plcc packages. Moto did 
list them as releasable parts at one time (often SC parts were later 
released to the great unwashed public after the original client had 
moved on). I wouldn't know where to find the data sheets for these. 
Somewhere in the depths of my garage, but the boxes in there are stacked 
4 high and 6 deep. The 84 pins may imply an external address/data bus.

I've just googled for MC68HC11 - PH8, M?, N? and G5. All data sheets are 
still available. I suggest you look at these, plus the P and K series 
just in case. This should at least point you in the right direction. I 
also find it very useful to find the vector table, analyse the ISR's 
and, particularly find the initialisation code. This will normally 
reveal all abouyt the peripheral map.

Cheers

Al

John Dyer wrote:

> "Everett M. Greene" <mojaveg@mojaveg.iwvisp.com> wrote in message
> news:20041105.79B3220.8244@mojaveg.iwvisp.com...
> 
>>"Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
>>
>>
>>>As for the assembly code, begin by trying to identify the blocking
>>>structure of the code. ie:- use a highlighter pen to show where bits of
>>>sub-routines begin and end. Be prepared to have several goes at this bit
> 
> as
> 
>>>you will not necessarily get it right tghe first time through. This can
>>>probably bnest be accomplished from following the reset vector jumps and
>>>walking through the code bit by bit.
>>
>>You can automate this to a very high degree by building
>>a symbol table and noting which addresses are referenced
>>by JSR/BSR (procedures) and which are referenced by the
>>other instructions (data).  Data areas greater than two
>>bytes on the 68XX family tend to be character string
>>constants and can be tested for content to distinguish
>>between that and address constants with a high degree of
>>success.  [There won't be much character string data in
>>an ECU.]
> 
> 
> Thanks for the suggestions guys, but I am pretty experienced
> at reverse engineering by dis-assembly. I have already re-built
> the disassembly as an asm file, identified all the data areas and
> tables, and can actually re-assemble the code to give a byte-by-byte
> comparison with the eprom! Using the 2500AD X68C11 assembler
> allows me to generate a cross-reference listing which is very useful
> as it show who calls who and how often!
> 
> However, as you probably well know, making serious sense of 11,000+
> lines of code still requires a BIG effort, particularly as there are
> hundreds of boolean type flags!
> 
> I would be prepared to put that effort in but the main problem
> is identifying the cpu pins (84 pin plcc package). The cpu is
> a 'sc' part, with some extra hardware which is difficult to identify
> without a datasheet or pinout. There are extra port addresses which
> go beyond those normally found in a hc11 core, and also a couple
> of extra interrupt vectors below the usual range!
> 
> Even more difficult is identifying some unusual ic packages that
> have custom Denso markings and odd dil packages. I suspect
> these are 'surge-suppression' type components but you still have
> to find what are inputs and outputs in order to identify what
> the hardware is connected to - oh well, always a good project
> when I retire......
> 
> 
> 
>