strange behavior of a P89C51RC Philips microprocessor

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!

E.L.

Reply to
Las
Loading thread data ...

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.

Reply to
nospam

Las schrieb:

After a reset, or after a power cycle?

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ß.
 Click to see the full signature
Reply to
Tilmann Reh

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.

E.L.

Reply to
Las

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.
 Click to see the full signature
Reply to
Nicholas O. Lindan

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.