PG302

The PG302 is a flash programmer produced by the now-defunct Iguana Labs, who provided kits and tutorials for learning how to program micro-controllers in the early 2000s. I use the programmer to write programs onto Atmel 89C2051 chips that cost less than two dollars each.

Using the PG302 with a computer

Iguana Labs provided a program for Windows that communicated with the programmer, allowing us not only to program chips, but to read programs from the chips, lock them, erase them, or verify their contents. There being good open-source tools for developing 8051 programs *nux, like [MCU 8051 IDE], I would prefer to use the programmer in Linux or Mac. The three options for this out-of-the-Windows use are

1. Use [PG302-Linux], a program the author admits is buggy. I haven't had success with it yet.
2. Use a program intended for direct serial communication, like GtkTerm. I have had seeming success using the protocol to communicate with the PG302, using the protocol provided with PG302-Linux. For example, I open a serial port at 57600 baud, 8 bits, 1 stop bit, no parity, no flow control, to a serial cable connected to the programmer. Then I can issue commands like "3", which requests the chip checksum. For an example session, see below. For the complete protocol, see http://pg302.sourceforge.net/protocol.html
3. Write a program to provide a GUI like the original PG302 control program for Windows. This could be done in Cocoa for Mac, with I/O Kit for serial communication, and a window with pull-down menus to select speed, buttons for various commands, and a file selector for reading, writing, and verifying files.

Uploading a program via serial

Use a program that allows you to send hexadecimal or binary data over the serial line.

1. Create a serial session between the computer and the programmer, at 57600 baud, 8 bits, 1 stop bit, no parity, no flow control. Set the output to "No line end," i.e. no CR nor LF when you press return.
2. Reset the programmer by unplugging it and plugging it in.
3. Send the letter "P", capitalized, as are all the letters that follow.
4. Check for the reply "Y".
5. Send the hexadecimal value 0. (Was incorrectly listed here before: Send the numeral "0".) This represents that the chip is not an AVR micro-controller.
6. Send the hexadecimal value 1 (Use "send hexadecimal data"—It's in the View menu of GtkTerm)
7. Send the hexadecimal value 1 again. These indicate to the programmer to look for a chip manufactured by Atmel.
8. Check for the reply "N" which means "send the next line of the program"
9. Send the first line of the hex file (which your assembler generated) as text, including the colons, like ":0030A701"
10. Check for the reply "N", or "I" which means that line does not have the proper checksum.
11. Repeat for each line in the hex file in order, until the last line, which should start with ":00" and end in "FF" is sent
12. Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.

Trouble with serial upload

Using CuteCom in Linux I go through the whole protocol, including getting verification of no errors at the end, but the chip doesn't work in-circuit. When I load the very same hex file from Linux via USB<>serial and from Windows 98 via PG302, only the chip loaded via Windows works. I can even use the Linux setup to verify the code, programmed from Windows, using the verification protocol.

What I have discovered is that the code on a chip matches verify and read, but not program. In other words, something translates in the program cycle, even though the programmer accepts and verifies each line of code. This indicates to me that there might be more to the programming code than the given protocol. Perhaps the hexadecimal data sent just before the lines of data is the wrong code.

To troubleshoot this, we should determine what the PG302 software is sending to the serial port during a program-cycle. The software has a very short waiting period, less than two seconds, before it declares the programmer has not responded in time, so we can't merely do it by hand over a null modem cable. Rather, we need to program a micro-controller or computer program to respond as if it were the programmer.

However, I was able to reply quickly enough with a Y at the beginning of the program cycle, using a null-modem cable, so that I could see that the sequence was to send an ASCII P, followed by a HEX 0, not an ASCII 0 as I had been sending...Aha! I was confused by the use of the convention of putting ASCII signals in quotation marks on the protocol listings. But I should have noticed the binary equivalents right next to the codes. Problem solved? Testing underway.

The problem seems to lie with the burnt code not matching the sent code, even though verification passes.

See also

Atmel, a manufacturer of 8051 devices: http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx