Hi Dennis,

A question for you about your programming code: does it issue a chip erase before starting programming?

Not implicitly, but by explicit command line option.

The problem Parviz is running into I believe is because the AT89S53 and AT89S8252 have an auto-erase feature, while the AT89S51 and AT89S52 do not; it would appear the software he is now using doesn't issue the chip erase when the chip is an 'S51 or 'S52. (Maybe it's not checking the chip signature to know just what chip it's talking to.)

Ahh, you're quite probably on to something there.

Of course with your source he will be able to modify the code to issue this chip erase if it doesn't do it already.

Yes, that would be a 1-line deletion, but code modification may not be required (for that purpose, at least). My program has a "-e" option to erase the chip before programming:

C:util>isp8252c -h

ISP8252C 1.00.01, (C) Copyright 1998-1999 by Daniel L. Henry.
Atmel AT89S8252 In-System-Programming Utility

Usage: isp8252c [-bBdDehipPvV] [-c comm_port] [-f codefile]  [-F datafile]
                [-l lock_bits] [-s pace_clks] [-u code_fill] [-U data_fill]

-b, -B        Blank check code (b) and/or data (B) memory
-c comm_port  ISP communications port name (default "COM1")
-d, -D        Dump code (d) and/or data (D) memory to standard output
-e            Erase and verify chip (both code and data memory)
-f codefile   Intel HEX file filename for code programming or verification
-F datafile   Intel HEX file filename for data programming or verification
-h, -?        Output usage information to standard output
-i            Ignore device errors
-l lock_bits  Program lock bits '1' (LB1), '2' (LB2), and/or '3' (LB3)
-p, -P        Program and verify code (p) and/or data (P) memory
-s pace_clks  ISP SCK pacing clocks
-u code_fill  Unused code memory fill byte (default 0xFF)
-U data_fill  Unused data memory fill byte (default 0xFF)
-v, -V        Verify code (v) and/or data (V) memory