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......
>
>
>
>
Reply by John Hudak●November 23, 20042004-11-23
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
Reply by BobGardner●November 21, 20042004-11-21
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......
Reply by John Dyer●November 6, 20042004-11-06
"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......
Reply by Everett M. Greene●November 5, 20042004-11-05
"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.]
Reply by Paul E. Bennett●November 4, 20042004-11-04
John Dyer wrote:
> Actually, I went to the local wreckers yard and got another ECU of the
> same type to pull apart, I sure don't want be without my car if anything
> should happen!!!!
That was sensible of you. :>
> I have disassembled the rom to give me an assembly language file that I
> can re-assemble correctly with a 6811 assembler, but if you know anything
> about disassembly, you will know that this is a long way short of getting
> an understanding
> of whats going on.
At least that is the simpler part of the work done.
> The next step is to work out the schematic diagram so I can see what is
> connected
> to what, buts its difficult as there are so many custom chips, I believe
> these chips
> are only surge supressors, but as they have custom Denso numbers, I can't
> get any
> info on them.
> The cpu has extra addresses above the normal end of the 68hc11 internal
> port space so there are obviously additional hardware features in the
> chip, and since
> I can't get a pin-out or info on the SC part, it all looks a tad to
> difficult.
>
> If you have any suggestions that might help I would be pretty pleased!!!
A couple of useful devices are a signal injector and a current trace probe.
Using these two together will allow you to clearly identify any tracks on
the PCB and their connectivity to other devices, no matter what they are.
A logic probe will also be quite usefule, especially if it is able to work
with any of the logic families. The very hard part is trying to work out
what all those black shiny impenatrable boxes are doing. I might suggest
that you should perhaps pick up yet another spare one that you can
dismantle to check out the individual hardware items for response
characteristics once you gain some idea of how they are connected
(identifying power supplies etc).
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 could also Highlight the JMP, JSR and RTS codes (I hope that is
correctly remembered for the family). Then make sure each one is really
what it purports to be and not data fields.
--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply by John Dyer●November 3, 20042004-11-03
"Paul E. Bennett" <peb@amleth.demon.co.uk> wrote in message
news:cmbb8j$j58$1$8300dec7@news.demon.co.uk...
> John Dyer wrote:
>
> > "Frankie" <goes@to.holliwood> wrote in message
> > news:4187c54b$2@x-privat.org...
> >> Can you suggest me some real application of MC68HC11 microcontroller?
> >> I need to know notorius industrial products that have this
> >> microcontroller (for example fuel injection, motor application,...)
> >>
> >> Thanks
> >>
> > I recently opened up the ECU box in my car, I didn't intially recognise
> > the cpu as it has an 'SC' part number. When I removed
> > the eprom and read it I recognised 68HC11 code.
> >
> > The ECU ia made by Nippon-Denso for my 1992 Mazda MS-6 car,
> > the cpu has some extra hardware, hence the SC designation, meaning
> > 'semi-custom'. The rom is jam-packed with highly optimised code written
in
> > assembly language, it has a lot of work to do yet only runs with 2MHz
> > internal clock. Extra support is provided by a 6821 PIA and a 6840 Timer
> > chip.
> >
> > I have tried to get info on the whole unit but its now to old, Motorola
> > does not release info on SC parts, and Denso does not release any
> > technical info on its products, but hey - life wasn't meant to be easy!!
>
> The fact that you have already opened the box (and probably due to its
age)
> will definitely have invalidated any warrantry you had on that unit. So,
if
> you are so inclined to find out more, start reverse engineering the unit.
> You may get to figure out what they added.
>
> As to the level of work the processor does, it may not need to be that
> great a load especially if the added hardware bits do most of the grunt
> work with the parameters being updated once in a while.
>
> You probably won't put this unit back on your car (might be too much of a
> death wish).
>
Actually, I went to the local wreckers yard and got another ECU of the same
type to pull apart, I sure don't want be without my car if anything should
happen!!!!
I have disassembled the rom to give me an assembly language file that I can
re-assemble correctly with a 6811 assembler, but if you know anything about
disassembly, you will know that this is a long way short of getting an
understanding
of whats going on.
The next step is to work out the schematic diagram so I can see what is
connected
to what, buts its difficult as there are so many custom chips, I believe
these chips
are only surge supressors, but as they have custom Denso numbers, I can't
get any
info on them.
The cpu has extra addresses above the normal end of the 68hc11 internal port
space so there are obviously additional hardware features in the chip, and
since
I can't get a pin-out or info on the SC part, it all looks a tad to
difficult.
If you have any suggestions that might help I would be pretty pleased!!!
Thanks,
John
Reply by Paul E. Bennett●November 3, 20042004-11-03
John Dyer wrote:
> "Frankie" <goes@to.holliwood> wrote in message
> news:4187c54b$2@x-privat.org...
>> Can you suggest me some real application of MC68HC11 microcontroller?
>> I need to know notorius industrial products that have this
>> microcontroller (for example fuel injection, motor application,...)
>>
>> Thanks
>>
> I recently opened up the ECU box in my car, I didn't intially recognise
> the cpu as it has an 'SC' part number. When I removed
> the eprom and read it I recognised 68HC11 code.
>
> The ECU ia made by Nippon-Denso for my 1992 Mazda MS-6 car,
> the cpu has some extra hardware, hence the SC designation, meaning
> 'semi-custom'. The rom is jam-packed with highly optimised code written in
> assembly language, it has a lot of work to do yet only runs with 2MHz
> internal clock. Extra support is provided by a 6821 PIA and a 6840 Timer
> chip.
>
> I have tried to get info on the whole unit but its now to old, Motorola
> does not release info on SC parts, and Denso does not release any
> technical info on its products, but hey - life wasn't meant to be easy!!
The fact that you have already opened the box (and probably due to its age)
will definitely have invalidated any warrantry you had on that unit. So, if
you are so inclined to find out more, start reverse engineering the unit.
You may get to figure out what they added.
As to the level of work the processor does, it may not need to be that
great a load especially if the added hardware bits do most of the grunt
work with the parameters being updated once in a while.
You probably won't put this unit back on your car (might be too much of a
death wish).
--
********************************************************************
Paul E. Bennett ....................<email://peb@a...>
Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/>
Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE......
Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details.
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply by TheDoc●November 2, 20042004-11-02
"Frankie" <goes@to.holliwood> wrote in message
news:4187c54b$2@x-privat.org...
> Can you suggest me some real application of MC68HC11 microcontroller?
> I need to know notorius industrial products that have this microcontroller
> (for example fuel injection, motor application,...)
>
> Thanks
>
>
I put about 2 dozen of them in a balloon and filled it with clear epoxy..
shaped a "flat" for the base and used it as a paper weight.. !
Reply by John Dyer●November 2, 20042004-11-02
"Frankie" <goes@to.holliwood> wrote in message
news:4187c54b$2@x-privat.org...
> Can you suggest me some real application of MC68HC11 microcontroller?
> I need to know notorius industrial products that have this microcontroller
> (for example fuel injection, motor application,...)
>
> Thanks
>
I recently opened up the ECU box in my car, I didn't intially recognise the
cpu as it has an 'SC' part number. When I removed
the eprom and read it I recognised 68HC11 code.
The ECU ia made by Nippon-Denso for my 1992 Mazda MS-6 car,
the cpu has some extra hardware, hence the SC designation, meaning
'semi-custom'. The rom is jam-packed with highly optimised code written in
assembly language, it has a lot of work to do yet only runs with 2MHz
internal clock. Extra support is provided by a 6821 PIA and a 6840 Timer
chip.
I have tried to get info on the whole unit but its now to old, Motorola
does not release info on SC parts, and Denso does not release any
technical info on its products, but hey - life wasn't meant to be easy!!