Need to run old 8051 firmware

Hello all



I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit 
(MCU). The MCU is now obsolete (it's from the late 1980s).



The firmware is compiled from several thousand rows of assembly language. It 
would take a long time to understand the code and re-program it in C.



So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
code without any changes to the code.



Any one here had any luck with this kind of problem?

Smith schrieb:

> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit 
> (MCU). The MCU is now obsolete (it's from the late 1980s).
> 
> The firmware is compiled from several thousand rows of assembly language. It 
> would take a long time to understand the code and re-program it in C.
> 
> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
> code without any changes to the code.

Unless you have an FPGA implementation of /exactly/ the 537, it probably
won't work. Remember that this MCU also contains very many special
function registers that most probably are used by the software, but not
covered by the available, more "generic", IP cores.

Several thousand lines of 8051 assembly, however, don't appear too much
to port. If you have the sources (as it sounds), you can probably find
the SFR-relevant code sections rather easily and port the application
(still in assembly language) to your new implementation on any current
8051 - or an IP-core in an FPGA.

Unless you have an FPGA in your new design anyway, I would however
suggest to look for a new flash-based 8051 MCU. It will probably be less
porting expense. Have a closer look /why/ the 537 was choosen for this
application - was it the number of ports, or any special peripheral
hardware function? Get a modern chip that fits these requirements best.

"Without any changes to the code" is not possible IMHO.

Tilmann

On Mon, 19 Apr 2010 15:53:25 +0200, "Smith" <smith@donotwantmail.com>
wrote:

>Hello all
>
>
>
>I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit 
>(MCU). The MCU is now obsolete (it's from the late 1980s).
>
>
>
>The firmware is compiled from several thousand rows of assembly language. It 
>would take a long time to understand the code and re-program it in C.
>
>
>
>So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
>code without any changes to the code.

There are lots and lots of MCS-51 microcontrollers still on the market.
Silicon Labs, Atmel, and Infineon among many others. I'd look there
first, before committing to instantiating an FPGA core.

-- 
Rich Webb     Norfolk, VA

Do you need one 80537, a few, or lots of MCUs?

Smith wrote:
> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit 
> (MCU). The MCU is now obsolete (it's from the late 1980s).
> 
> The firmware is compiled from several thousand rows of assembly language. It 
> would take a long time to understand the code and re-program it in C.
> 
> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
> code without any changes to the code.

http://www.opencores.com/project,8051

Note that you still have a lot of road ahead of you, should
you go down this path.  Recall that you will also need to
design the various "integrated I/Os" in that '51 variant.
And, *hope* there are no subtle timing exploits used in
the code.

> Any one here had any luck with this kind of problem?

"Several thousand rows (?)" of assembly language isn't a
particularly big design.  *If* you have the sources
*and* the schematics *and* knowledge of the application
domain, this would probably be easier to reimplement
from scratch.

If you *don't* have the sources, but *do* have the other
two items, you can mechanically reconstruct them and
back-annotate as appropriate (to add semantic value).

If you have only knowledge of the application domain,
then you have to deduce the hardware requirements as
you are back-annotating.  Your knowledge of what the
device is likely *trying* to do gives you the foundation
for these deductions.

This last case is the most challenging though it is still
do-able.  When I bid reverse-engineering jobs like this,
I figure on generating commented source code at a rate of
about 2-4KB/week.  So, a 16K image is only a month or two
from start to finish.  (If the image was created by a
*compiler*, my throughput goes up dramatically!)

Look here:

http://www.littlediode.com/components/80C537_Integrated_Circuit.html?NO_COOKIE_WARNING=2&ti=ca697e2b03146363b5a9601ab6592a49&xid=60b420f64a0bf7ac68d8779fdb2b8008

I need about 100-200 parts.

"Stefan Brr&#4294967295;ring" <stefan___@broering.de> wrote in message 
news:4bcc68c8$0$3291$8e6e7893@newsreader.ewetel.de...
> Do you need one 80537, a few, or lots of MCUs? 

Smith wrote:
> Hello all
> 
> I need to run an old firmware for a Siemens SAB 80C537 microcontroller unit 
> (MCU). The MCU is now obsolete (it's from the late 1980s).
> 
> The firmware is compiled from several thousand rows of assembly language. It 
> would take a long time to understand the code and re-program it in C.
> 
> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
> code without any changes to the code.
> 
> Any one here had any luck with this kind of problem?

I'm with the rest of the folks here:

(a) Why try to rewrite this in C?  Why not port this to a new 8051 using 
the existing code as a base?  If the code is well written and commented 
then the only parts that will have to be changed will be the parts that 
talk to hardware, although depending on the code and the application 
this may take some head-scratching.

(b) You're probably far better off to make this work with some new spin 
of an 8051, with the peripherals that you need to get the job done.

(c) I could easily see trying to exactly replicate an old application, 
complete with snazzy peripherals and maybe timing loops, to be a 
never-ending hassle.  You know the old saw about the last 10% of the 
work taking 90% of the time?  I think this would be a way to design a 
project where the last 1% of the work takes 99% of the time.  If I'm 
wrong, it'd only be because you'd see the last 0.1% of the work taking 
99.9% of the time.

Software is cool because it's easy to change, so you can use it to help 
your product dodge around changing marketing requirements and hardware 
issues.  Chaining your whole project to a large chunk of dead code is 
just asking for a nightmare.

-- 
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com

I found a company in UK that auto convert 8051 assembly code to C (and then 
hand optimize a few things).

www.microapl.co.u


"D Yuniskis" <not.going.to.be@seen.com> wrote in message 
news:hqhpi9$f65$1@speranza.aioe.org...
> Smith wrote:
>> I need to run an old firmware for a Siemens SAB 80C537 microcontroller 
>> unit (MCU). The MCU is now obsolete (it's from the late 1980s).
>>
>> The firmware is compiled from several thousand rows of assembly language. 
>> It would take a long time to understand the code and re-program it in C.
>>
>> So I'm thinking of using an 8051 IP-core for a FPGA and run the firmware 
>> code without any changes to the code.
>
> http://www.opencores.com/project,8051
>
> Note that you still have a lot of road ahead of you, should
> you go down this path.  Recall that you will also need to
> design the various "integrated I/Os" in that '51 variant.
> And, *hope* there are no subtle timing exploits used in
> the code.
>
>> Any one here had any luck with this kind of problem?
>
> "Several thousand rows (?)" of assembly language isn't a
> particularly big design.  *If* you have the sources
> *and* the schematics *and* knowledge of the application
> domain, this would probably be easier to reimplement
> from scratch.
>
> If you *don't* have the sources, but *do* have the other
> two items, you can mechanically reconstruct them and
> back-annotate as appropriate (to add semantic value).
>
> If you have only knowledge of the application domain,
> then you have to deduce the hardware requirements as
> you are back-annotating.  Your knowledge of what the
> device is likely *trying* to do gives you the foundation
> for these deductions.
>
> This last case is the most challenging though it is still
> do-able.  When I bid reverse-engineering jobs like this,
> I figure on generating commented source code at a rate of
> about 2-4KB/week.  So, a 16K image is only a month or two
> from start to finish.  (If the image was created by a
> *compiler*, my throughput goes up dramatically!) 

Smith wrote:
> I found a company in UK that auto convert 8051 assembly code to C (and then 
> hand optimize a few things).
> 
> www.microapl.co.u

Note that you don't have to "go to C".  You can just
leave the code in ASM and tweek the I/Os as needed.

The only advantage to an FPGA approach is if you can
purchase it packaged and bonded out to *exactly* the
same pinout.