I've made a parallel port programmer (with HCT14 as interface)
and a simple C source to programm the Atmel's S52, ISP.
My baby-steps were (software only):
1. send "programming enable" and check for 0x69.
2. get signature byte 0, 1 and 2.
3. erase chip
4. read lock bits
5. read flash memory
Up to this point, step 2 always returned expected data.
Then I've added code to write the flash memory,
but the code was wrong, it didn't wait enough time
between byte writes.
From then on, step 2 started returning invalid data.
At first, instead of 1E, 52, 06, it returned 1F, 53, 07
(bit 0 was always set).
I didn't know why this was happening, and continued
writing to flash memory with code that works too fast.
Finally, the signature I now read is all FF.
I still get 0x69 for step 1.
I've changed the write_flash prog to consume more
time between byte writes, and it works now,
since I can read back the contents as written.
Read/write lock bits works fine.
Only the device signature is broken.
Anyone had a similiar problem?
How is it possible that a device
signature got erased somehow?
And NO, I didn't yet executed any code
on the chip, but reading the flash memory
shows the expected data.
Reply by Jim Granville●September 4, 20112011-09-04
On Sep 4, 8:52=A0am, "aleksa" <aleks...@gmail.com> wrote:
> Anyone had a similiar problem?
> How is it possible that a device
> signature got erased somehow?
It may be that 1 is not erased but over-pgm'd.
Device signatures are often not cast-in-silicon, but pgm'd at the
factory along with 'other undeclared bits'. - you've just hit some of
that by accident.
It is also why most Pgmrs allow users the option to Skip-over
signature messages ;)
Reply by aleksa●September 4, 20112011-09-04
> And NO, I didn't yet executed any code on the chip
I did now, a small piece of code to toggle the LED.
Reply by Tilmann Reh●September 6, 20112011-09-06
[No/incorrect device signature on 89S52]
We also had 89S52 devices with no or incorrect signature. Some were
programmed as 89S51 - however, regardless of the signature, the chips
themselves were all correct (and also had the larger memory and the
Seems like Atmel has some reliability problems at the step where the IDs
are programmed. I assume that is one of the last steps in the production
process, and eventually several chips got through without being
programmed, or programmed with the ID of a former 89S51 run.