AT89S52 chips not validating correctly

[mik3ca]

I made myself the followint circuit that is meant to program an AT89S52 chip serially using a PC parallel port:

Now I know the parallel port works fine because I used it with my other programmer so that isn't the issue. When I try to program the chip, I look at the leds (shown on the right) and the output isn't what it should be.

For example, if I only did the following code:

Mov P2,#0FFh
mov P0,#0FFh
sjmp $

then all lights should go off after programming but they dont.

Now in my software end of things, I noticed that when I tried to verify the bytes after chip erasure, failure occurs at different locations. On one attempted erase execution, the validation successfully validated 126 out of 384 bytes and stopped at 127. On another, the erase only validated successfully at 11 bytes and stopped at 12.

In my program I made it where there is a 10 microsecond delay between the time that any pin changes state. This means that if all lines were low and I wanted to set data to be one and raise the clock then It would take 20uS. 10 to set the data, and 10 to raise the clock.

I also included a slow mode as well for anything that doesn't process consecutive bytes such as erase. For those operations, I put in a 2mS delay.

So what is the problem? Is my chip officially garbage or do I need a giant erase time or what?

 

[Pommie]

You need to get a programmer that works. You're just guessing where the problem is.

Mike.

 

[mik3ca]

I'm starting to think I need capacitors on the clock and input lines to eliminate noise going in. What capacitor values are best?

 

[Pommie]

And, that's one more guess at whats wrong. Get a working programmer and at least eliminate that.

Mike.

 

[mik3ca]

Today I soldered on an additional 47nF ceramic on my PCB across the power lines closer to the micro and that does seem to help since one test passed since the change.

 

[HarryC]

I haven't used the Atmel parts yet, but OTHER manufacturer's 8052s can be put into Test Mode by fooling around with /PSEN. It's best to leave ALE and /PSEN utterly alone if you're running from internal Flash. Test Mode is NOT documented in the distribution datasheet. Lift a leg or remove the LED that you have hanging on /PSEN and see if that cures it. /PSEN should normally be weakly HIGH (internally) when you're running from internal code space.

"No, no, no, don't tug on that. You never know what it might be attached to." ~ Buckaroo Banzai

And I'll echo the other three posters: you're spinning your wheels until you get a working device programmer. If it doesn't program and verify EVERY TIME, then it's untrustworthy.

 

[mik3ca]

Ok this is extremely weird. When I added that 47nF capacitor and hooked my circuit directly to my laptop back parallel port, everything is working.

Now because my laptop hinges broke, I had to take the lid off and use an external monitor to plug it in to the laptop so I can see what I am doing.

Now when I try to program the thing, I get the same issues as before. I wonder if all the wires might have something to do with it. I'm thinking radiation that the laptop lid blocked?

I also tried using a parallel port extension cable as well but that gave worse results.

 

[mik3ca]

I added a snapshot of my physical layout. The blue monitor cable was recently added because as you can see the laptop lid was removed and I needed a way to see what I'm doing. Also my programmer labelled "circuit" is directly attached to the PC (plugged into the parallel port). The cable on the far left connected to the laptop is a USB cable to my phone. Had I removed the blue cable and had my lid working then the programmer would work. Also, the twisted red and black wire appearing on top of the circuit is the 5V power supply. I twisted it as an attempt to eliminate interference.