I am working on AT89C51, the problem is that although my assembly code is working perfectly on the pinnacle simulator it gives a verification failed error when I try to write it on the programmer using ezdl4 s/w.
Simple programs with commands to send and recieve data on the serial port work fine and get written on the controller, but when I use commands like ACALL or MOVC in my code it gives me the verification failed error.
Example of a Code working on the programmer.
ORG 0H
MOV TMOD,#20h MOV TH1,#98h MOV SCON,#50H SETB TR1
ECHO:
RECV: JNB RI,RECV MOV A,SBUF CLR RI
MOV SBUF,A SEND: JNB TI,SEND CLR TI
SJMP ECHO
END
Example of a Code not Working
MOV DPTR,#MYDATA
H_1: CLR A MOVC A,@A+DPTR JZ B_1 ACALL SEND INC DPTR SJMP H_1
SEND: MOV SBUF,A JNB TI,$ CLR TI RET
MYDATA: DB "SeriaL Data Transmission 123",0H
B_1: HERE:SJMP HERE END
Note: I have a 12Mhz crystal and so i am using a baudrate of 300bps.
Could anyone please tell me whats the problem asap. Thank you
The programmer I am using is definitly for AT89C51, though it is kindof handmade. The programmer uses a AT89C51 chip to program so there is no chance dat its not compatible.
The only thing i am asking is wether its possible dat the programmer has some fault and is not burning some codes?
The programmer I am using is definitly for AT89C51 that only means it it likely to be faulty. The Atmel programming is so finicky that 99% of the kitchen table approaches that 'work' has problems. This is not whether is is somebodys wet dream of how to program Atmel, it is that if ANYTHING is 1% or less off the Atmel expectations it will, most likely fail. As an example replacing a VHC chip in somebodys illusion of an Atmel programmer with an equivalent HC chip makes the 'working' design fail. Not to mention that there are ';designs' on the web that are guaranteed not to work unless your PC is brand x running Windows rev y. That, of course, is NOT stated.
The only thing i am asking is wether its possible dat the programmer has some fault and is not burning some codes? not just 'possible' but likely
Erik
A programmer built using a AT89C51 is not the same as a programmer built to program a AT89C51.
Your programmer does not seem to correctly program your chip. Isn't that an indication that you should get a different programmer?
Another thing: what file formats does it make use of? Binary? Intel-Hex? Other format? Maybe it has buggy code to read the input file.
My programmer uses intel-hex file, and I guess I will get a new programmer.
Actually this particular programmer is used by many people and it works fine, maybe mine is faulty.
Aynways thanx for your help.
Then Find out.
Try your program / chip on their programer and see if they work.
I took my programmer to the persom form where I bought it. My programmer was working perfectly at his place and writing the files which gave me a verify failed error.
I used the same programmer, software and controller but was working perfectly fine at his place. The only difference was that we used different power supplies. He was proabably giving somewhere around 15V and I usually give it somewhere between 16-18V. Now is it possible that due to the different voltage levels my programmer burns some codes and gives error on others?
programming requires absolute precision of everything.
I actually doubt your voltage is the problem, but my first action would be trying to fix that.
If the 'programmer' is connected to the serial port, read on, otherwise tell us how it is connected to the PC:
My best guess is that the 'programmer' is 'cheating' on the RS232 interface which will make it work with some PCs and not with others.
Did the 'programmer' work before you changed your PC?
If you can, see if the "programmer" contains a MAX232(equivalent)
"He was proabably giving somewhere around 15V and I usually give it somewhere between 16-18V."
As Erik says, parallel programming does require close adherence to the specifications.
So, what is the specified power supply for this "programmer"? If you are operating it out-of-spec, then all bets are off; there is no reason to believe that it will operate correctly - you are in undefined operation territory.