Hi Guys.
I’m looking for advice from anyone who has experience dumping an older 40-pin PDIP AT89C51, specifically the AT89C51-20PC (date code 1999). I’m aware that the early AT89C51 revisions don’t require glitching. (Just a short erase pulse while in programming mode). This changed in 1999.
I’ve been able to power-glitch the device while it’s running and capture extra data on the UART, so I’m confident I’m on the right track. The glitch duration and depth look correct based on the oscilloscope, but the timing window is extremely narrow, and I’m struggling to hit it consistently.
To better understand the timing, I wrote some test firmware for another AT89C51 with the same date code. With a dedicated output pin acting as a trigger, it becomes much easier to line up the glitch, and under those conditions I can reliably force the chip to dump additional data.
Of course, the target device I’m trying to extract data from doesn’t have this trigger pin I can use as a timing marker, so I’m back to guessing based on program behavior.
I used a logic analyzer to record the serial output and get a ballpark region for when the glitch should occur, and the extra output is random, but I’m still not getting consistent results.
Given that this device is about 25 years old, I’m wondering if anyone who has dealt with these classic AT89C51 parts has recommendations. Tips on timing strategy, repeatability, environmental factors, or known quirks of this specific revision would be greatly appreciated.
Knowing that the code was written long ago (in assembly) I assume the “PutString” routine exists something like this:
PutString:
clr a
movc a,@a+dptr
;in the test code I set a trigger point here
jz PutString_exit ; stop if char =0 (I am trying to glitch here)
lcall outchar
inc dptr
sjmp outstr
PutString_exit:
ret