Forums

Need to run old 8051 firmware

Started by Smith April 19, 2010
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&#2013266166;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.