Actually most of the jobs have done by control chip, 89C51 that runs EZ52.C. The 89C51 generates signals used to set modes, provide address and data lines, control erasing/programming voltage and pulsing the programming pulse. The host PC's software is just to send a command using ASCII letters to coordinate download sequencing and provide binary image converted from the original HEX file.
Currently the programmer board with EZ52.C has seven commands;
|
|
|
|
|
use to set the number of byte to be read, or programmed |
|
|
read hex code from the chip with the number of byte set by s command |
|
|
get chip information |
|
|
get chip info for simple host interfacing |
|
|
erase the chip |
|
|
set write mode, the hex code that received from the host PC byte by byte will write into the chip |
|
|
write lock bit |
Let see how each command responded with ASCII letters sent from terminal. The format of terminal that uses serial port is 9600 bps 8n1. You may test the programmer board with, say HYPER termial, or any terminal emulation program.
Example below refers to the hello1.hex
and the 89C52 put in the ZIF socket.
The intel hex file of hello1.hex is here;
:03000000020003F8
:0F000300758108E4787FF6D8FD75A0FF02001222
:10001200B2978590907BE87A04DBFEDAFC7C037D64
:03002200E880ED86
:00000001FF
:00000001FF
With 'ENTER' code (0x0d), the programmer board return title message.
We use this command to see is there a programmer board connected to COM
port, say.
| Easy-Downloader
V2.0 for ATMEL 89C51/52/55
> |
'p' command To see what chip
is in ZIF socket?
| >p52,36,0
ok > |
We get signature byte=52, nonblank 36 bytes, byte counter = 0: It means the programmer board found 89C52 in the ZIF socket, the number of byte that is not FF is 36 bytes and set counter is 0.
'e' command Erase the chip.
| >e
ok > |
The programmer board will erase chip.
'p' command again Check all byte is FF or not.
| >p52,0,0
ok > |
Now we get signature byte = 52, non blank = 0, byte counter = 0
The chip is now blank!, then set the number of byte to be programmed,
e.g. 37 bytes
| >s37
ok > |
There're 37 bytes to be programmed.
'w' command set write mode, the loop for receiving hex code from host PC is set up and flow control uses XON/XOFF. Since the terminal program can not send the binary code with such flow control, this job is then left for a dedicated software, say EZ3 Uploader. This command may not easy to test with terminal program.
for(i=0; i< 37 ; i++)
{
wait for XON
send byte to the board
get XOFF
}
Now read back to verify the programmed code with hex file.
with 'r' command
| >r020003758108E4787FF6D8FD75A0FF020012B2978590907BE87A04DBFEDAFC7C037DE880ED
ok > |
The hex code is read back as the ASCII letters, no NEW LINE, no error checking. The host PC must compare this hex code with the buffer memory if it corrects, that's OK.
if you have to lock the code then use;
'l' command
| >l
ok > |
to check all byte is locked, use command 'r' to read back again
| >rFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
ok > |
That's all.
Note:
1. every command when success their job, it
will return prompt 'ok'.
2. sending byte to programmer is simple binary
image, no error checking, each byte the programmer board received
will write to the chip. The Address is automatically counting up from 0
to MAX address (number of byte to be programmed).
3.The sequencing described above is just to
provide all functions needed to finish download or write the hex code automatically.
No separate functions, say ERASE, TEST BANK, PROGRAM, VERIFY.
4. Flow control is software method using
XON = 0x11 and XOFF = 0x13.
If you want to see the flowchart of above sequencing (lock command is optional), see below;
For details of what control chip do at low level hardware operation, study each function in EZ52.C and ATMEL Programming Data sheet.
I hope the material herein would enables the
programmer to develop his/her own host software that suitable for their
needs easily. I shall be grateful to you if you could contribute your work
for others. Any confusing, please let me know. By now I'm very busy,
so far I'd like to add signature byte reading for 89S8252 and 89S53 chips.
When we put such chip into ZIF, the programmer board then can recognize
and send their signature byte to the host software. So the host software
will know that chips is put in the ZIF. This is very easy if you use Visual
Based Developer Tool, but for me is quite difficult. If some of you free,
I'd appreciate if you could help.
