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?

Reply to
Smith
Loading thread data ...

Smith schrieb:

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

Reply to
Tilmann Reh

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
Reply to
Rich Webb

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

Reply to
Stefan Brröring

formatting link

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.

"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!)
Reply to
D Yuniskis

Look here:

formatting link

Reply to
Stefan Brröring

I need about 100-200 parts.

Reply to
Smith

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
 Click to see the full signature
Reply to
Tim Wescott

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

formatting link

Reply to
Smith

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.

Reply to
D Yuniskis

Let's go with 200 parts.

Someone pointed you to a web site that listed the cost at roughly US $50 each at that quantity.

You would probably spend more that $10,000 moving the existing code to whatever new solution you found.

So unless you can find a replacement for less than zero dollars, it's less expensive to pay the (exorbitant) per-chip price.

Even though I think it would be "fun" to design it out, it's not responsible engineering.

RK

Reply to
d_s_klein

I'd try tweaking firmware first. Looks like this one is not standard 8051 deriviative. Has 32bit math MDU and 8 DPTR registers.

First thing I'd do is see if these odd features are being used. If not, it would be easy to port to another 8051 derivative. If so, porting challenge could range from a minor hassle to impossible. Then C port might be way to go.

I'd get a good firmware engineer to evaluate code before moving forward.

Reply to
Rumpelstiltskin

Perhaps a brief explanation of why might have been useful. Need to make some more old units, need to upgrade for a newer product?

One application I did many years ago was all hand-coded 6800 machine code. About 4k of it. This was input to the system by the switch and step method. So in an actual assembler, this should not be too much of a hassle even if the code is 2 or 3 times that size.

Others have indicated that the parts are available from at least one stockist. Unless you need special certification of the parts that would seem to be the way to go to make more of an old product.

On the other hand, if this is an update of the product-line then it would be much wiser to bite the bullet and select a more recent part offering that gives you the facilities you need. Then set to and understand the assembly code listing so that you can re-work the system and improve it as you go.

--
********************************************************************
Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

From the Keil web site:

The Infineon SAB 80C537 is an 8051 based CMOS controller with 21ch PWM,

8 DPTRs, WDT, 12ch ADC/8, Mul./Div Unit, 68 I/O lines, 4 Timers/Counters, 14 Interrupts/4 priority levels ROM-less, 256 Bytes On-chip RAM.

Talk about job security !!!

;-)

hamilton

Reply to
hamilton

In message , Smith writes

I know I have some here...

But that may be the cheaper option. Yes, I have done it before.

You can't do it. Simple as that. There are some 50+ 8051 cores. All different. From the standard 12 to 1 cycle systems.

On top of that they had different peripherals. So once you get your core, tune it to be the same as the one Siemens used you then have to get all the peripherals and get them to be have exactly as Siemens did. Then bolt them together.

The faster and cheaper option by far is to reverse engineer the code.

Why do you need to run this firmware? If you need to do 100-200 units to do the same thing go and get a cheap modern core with the same peripheral set. And start again.

This will be faster, more reliable and cheaper.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

it

It

First, I'd try and source the real silicon. An FPGA will lack the peripherals, and lacks the Analog options, so a precise clone will be _very_ difficult.

Failing getting the silicon, there are other, newer, parts with similar resources, including newer Infineon parts.

Do you have the ASM source ? How much code space, and is a move to on-chip code ok ?

-jg

Reply to
-jg

it

It

The 8031/8051 architecture or compatible MCUs are still being used. When I was at KODAK it was used in a couple of different parts of a minilab system for controlling and synchronizing motors. I recently interviewed with a avionics company that uses it for digital displays in the cockpit of the plane (it is easy to get certfied for the FAA).

Don't write it off yet...

Derek

Reply to
Derek Simmons

There are some 500 variants based on over 40 different cores. Whilst it is relatively easy to move C it will be a real dog to moves assembler.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

Chris H schrieb:

It does depend on programming /style/ more than on programming /language/.

If the device-related code (peripherals, special functions) is spread over all sources, with inline access/instructions and not commented, it's *much* work regardless of language.

If the code is well structured and commented, with modules dedicated to clearly defined tasks, it's not really a problem - also regardless of language.

Tilmann

Reply to
Tilmann Reh

In message , Tilmann Reh writes

For a high level language I would agree but we are discussing "several thousand rows of assembly language".

For most 8051 code the C will be the same for the core and it is only the peripherals that are different. Most of the other stuff like memory allocation and SFR's etc will be handled by the compiler. A recompile with a different 8051 target selected will solve many of the problems. With Assembler you can't do that.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.