PG302 - Revision history

Shawn: /* See also */

2013-11-15T22:21:10Z

Shawn at 22:14, 15 November 2013

2013-11-15T22:14:10Z

Shawn: /* Trouble with serial upload */

2013-11-12T21:47:12Z

Trouble with serial upload

← Older revision		Revision as of 14:47, 12 November 2013
Line 30:		Line 30:

	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.		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==		==See also==

Shawn: /* Uploading a program via serial */

2013-11-12T17:14:47Z

Uploading a program via serial

← Older revision		Revision as of 10:14, 12 November 2013
Line 13:		Line 13:
	#Send the letter "P", capitalized, as are all the letters that follow.		#Send the letter "P", capitalized, as are all the letters that follow.
	#Check for the reply "Y".		#Check for the reply "Y".
	#Send the numeral "0".		#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.
	#Send the hexadecimal value 1 (Use "send hexadecimal data"—It's in the View menu of GtkTerm)		#Send the hexadecimal value 1 (Use "send hexadecimal data"—It's in the View menu of GtkTerm)
	#Send the hexadecimal value 1 again		#Send the hexadecimal value 1 again. These indicate to the programmer to look for a chip manufactured by Atmel.
	#Check for the reply "N" which means "send the next line of the program"		#Check for the reply "N" which means "send the next line of the program"
	#Send the first line of the hex file (which your assembler generated) as text, including the colons, like ":0030A701"		#Send the first line of the hex file (which your assembler generated) as text, including the colons, like ":0030A701"

Shawn: /* Trouble with serial upload */

2013-11-12T17:12:22Z

Trouble with serial upload

← Older revision		Revision as of 10:12, 12 November 2013
Line 28:		Line 28:

	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.		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.

	==See also==		==See also==

Shawn: /* Trouble with serial upload */

2013-11-11T21:03:44Z

Trouble with serial upload

← Older revision		Revision as of 14:03, 11 November 2013
Line 26:		Line 26:

	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.		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.

	==See also==		==See also==

Shawn at 20:54, 11 November 2013

2013-11-11T20:54:42Z

← Older revision		Revision as of 13:54, 11 November 2013
Line 22:		Line 22:
	#Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.		#Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.

	====Trouble with serial upload===		====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.		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.		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.

	==See also==		==See also==

Shawn: added Trouble with serial upload

2013-11-11T20:13:16Z

added Trouble with serial upload

← Older revision		Revision as of 13:13, 11 November 2013
Line 7:		Line 7:
	#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.		#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.

	===~~Downloading~~ a program via serial===		===Uploading a program via serial===
	Use a program that allows you to send hexadecimal or binary data over the serial line.		Use a program that allows you to send hexadecimal or binary data over the serial line.
	#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.		#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.
Line 21:		Line 21:
	#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		#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
	#Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.		#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.

	==See also==		==See also==

Shawn: /* Using the PG302 with a computer */

2013-11-11T20:09:18Z

Using the PG302 with a computer

← Older revision		Revision as of 13:09, 11 November 2013
Line 4:		Line 4:
	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 [[http://mcu8051ide.sourceforge.net 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		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 [[http://mcu8051ide.sourceforge.net 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
	#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I haven't had success with it yet.		#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I haven't had success with it yet.
	#Use a program intended for direct serial communication, like GtkTerm. I have had seeming success ~~loading a program~~, 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		#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
	##I wrote "seeming success" because 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.
	#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.		#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.

Shawn at 19:45, 11 November 2013

2013-11-11T19:45:32Z

← Older revision		Revision as of 12:45, 11 November 2013
Line 4:		Line 4:
	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 [[http://mcu8051ide.sourceforge.net 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		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 [[http://mcu8051ide.sourceforge.net 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
	#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I haven't had success with it yet.		#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I haven't had success with it yet.
	#Use a program intended for direct serial communication, like GtkTerm. I have had success loading a program, 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		#Use a program intended for direct serial communication, like GtkTerm. I have had seeming success loading a program, 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
			##I wrote "seeming success" because 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.
	#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.		#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.

← Older revision		Revision as of 15:21, 15 November 2013
Line 37:		Line 37:
	==See also==		==See also==
	Atmel, a manufacturer of 8051 devices: http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx		Atmel, a manufacturer of 8051 devices: http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx

	Intel HEX, wikipedia's entry on the file type sent to the PG302. http://en.wikipedia.org/wiki/Intel_HEX		Intel HEX, wikipedia's entry on the file type sent to the PG302. http://en.wikipedia.org/wiki/Intel_HEX

	[[Category:Electronics]]		[[Category:Electronics]]

← Older revision		Revision as of 15:14, 15 November 2013
Line 1:		Line 1:
	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.		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, such as my Bike Speedometer, onto Atmel 89C2051 chips that cost less than two dollars each.

	===Using the PG302 with a computer===		===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 [[http://mcu8051ide.sourceforge.net 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		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 [[http://mcu8051ide.sourceforge.net 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
	#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I haven't ~~had success with it~~ yet.		#Use [[http://pg302.sourceforge.net/ PG302-Linux]], a program the author admits is buggy. I have had success by changing the speed to 9600 first with the Windows version, then moving the serial cable to my Linux box. I haven't yet successfully programmed a chip at 57600 baud.
	#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		#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
	#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.		#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.
Line 19:		Line 19:
	#Send the first line of the hex file (which your assembler generated) as text, including the colons, like ":0030A701"		#Send the first line of the hex file (which your assembler generated) as text, including the colons, like ":0030A701"
	#Check for the reply "N", or "I" which means that line does not have the proper checksum.		#Check for the reply "N", or "I" which means that line does not have the proper checksum.
	#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		#Repeat for each line in the hex file in order, until the last line, which should start with ":00", have "01" as the record type, and end in "FF" is sent
	#Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.		#Check for the final reply, "D" which means no errors, or "C", which means the hex file seems corrupt.

Line 32:		Line 32:

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

			To diagnose the problem, I created an arduino program to run on an Arduino connected to a MAX232I voltage-level converter, so that the Arduino's TTL-level logic could communicate with the RS-232-level serial port.

	==See also==		==See also==
	Atmel, a manufacturer of 8051 devices: http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx		Atmel, a manufacturer of 8051 devices: http://www.atmel.com/products/microcontrollers/8051architecture/default.aspx
			Intel HEX, wikipedia's entry on the file type sent to the PG302. http://en.wikipedia.org/wiki/Intel_HEX

	[[Category:Electronics]]		[[Category:Electronics]]