strange behavior of a P89C51RC Philips microprocessor

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
My company has a device that uses the 89C51. Somehow the flash memory is
getting corrupted. The device will not boot properly after a reset. When the
device is reprogramed it works ok. I know this is a general description
without much detail. I'm just looking for anyone who might have had similiar
problems with this device. Thanks!


Re: strange behavior of a P89C51RC Philips microprocessor

Quoted text here. Click to load it

Yes too vague.

Sound like you should try a different programmer.

If the part is C51RC+ then some silicon revisions required a programming
algorithm change. The symptom of programming with the original algorithm
was intermitant (time to time and device to device) failure boot correctly
on reset.

Check exactly which part number you have the problem with and check for
data sheet errata.


Re: strange behavior of a P89C51RC Philips microprocessor
Las schrieb:

Quoted text here. Click to load it

After a reset, or after a power cycle?

Quoted text here. Click to load it

We once had problems with a similar chip from Atmel. It turned out that
the ISP capable chips *require* an external voltage monitor that activates
the reset input of the MPU at power-down (or brown-out), otherwise the
code flash might be corrupted. The simple capacitor-driven reset circuit
is not OK, though it is explicitly mentioned in the data sheet...

Later, they published an application note about this (though the data
sheet is still unchanged, AFAIK).

Another question: how did you program the device? Parallel programmer
or ISP (if ISP: which PC software did you use?)?
In case of self-written ISP code: take care that the bootloader
requires all data of one programming record to be within one flash
memory row (take care of the boundaries in case of non-aligned HEX
code generated by many linkers).

Dipl.-Ing. Tilmann Reh
Autometer GmbH Siegen - Elektronik nach Ma▀.
We've slightly trimmed the long signature. Click to see the full one.
Re: strange behavior of a P89C51RC Philips microprocessor

Let me explain a little more: The product (call it product X) has an LCD
screen than reads out data to the user. We have product X installed world
wide in may different applications. Within the last 6 months we found
another application for using product X in 120 VAC motor control. Now we are
starting to see problems where product X's LCD is being reported as being
"blank". After initial investigation we found that reprogramming product X
would reestablish functionality to the device. I am gearing-up to go
in-the-field next week for three days to gather information at the site.
Basically to see if the device has been installed correctly and offer
support. We have developed our own progammer and software, which leads me to
think there maybe a setting that is being over looked. I browsed around the
Philips forum and found a few topics discussing the proper setting of the
status byte. I'm not sure what our current configuration is. I think our
next step will be to see if we can read back the memory and make a
determinition as to what is getting corrupted.

Thanks for your reply.


Re: strange behavior of a P89C51RC Philips microprocessor
Quoted text here. Click to load it

The first step is to be able to cause the fault on demand.  Until
you can do this any fix-it effort - design change etc. - is pointless.

If the product works in the old application but fails in the new
application then logic would have it that the application has some
effect on the product.

Is the product different in the two applications?  If the software has
change or the I/O has changed then these are obvious places to look.

Does the operator use X in a different way?  Are wires to X routed
past high power electricals?  Are the wires shielded?

You say the new app is AC motor control.  I imagine it is in an industrial
setting where line and electromagnetic noise is common.

If it were me I would suspect electrical interference:  It gets in
and somehow activates the ISP logic in the uC.

Have you tested the product for

o SWC (Surge Withstand Capability)
o Brown out
o Sharp and glitchless reset signals to the uC on power up and _down_
o Static discharge
o EM susceptibility

You will need an SWC tester and a static discharge test gun.  EM
susceptibility is best dealt with at a firm specializing in
this sort of testing.

Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline