On Sat, Jul 27, 2002 at 05:29:15PM -0500, Jay Jacobs wrote: I'm glad that you're using the PICLIST for TLVP debugging. I hope that everyone is OK with that as I read this list consistently. > Having one heckuva time getting any sort of a programer going. After I > stopped beating my head with the stupid stick I thought I had it working, > but nope, no go. I've used Tait's FPP Programmer (windows) and picprog > (linux -2.3c failed to work but 2.3d seems to run, but not proram) You're running a Linux 2.4 kernel. That's the reason for the minor update. I just checked the archives and verified that Jay was the same poster from before. So I already gave my short list: (short cable, test pins) so let's move on from there. > and one > concern I have is the setup/test screens... those are showing the lines > (pins) from the parallel port? Yes. Different Tait style programming hardware uses different pins for the various programming functions. Putting together a default .picprgrc that uses parallel port 0 and the default pins for the TLVP is on my list of things to do. > So that's where I should be testing the voltage? At the PIC socket. The HCT573 is nothing but a buffer between the parallel port pins an the socket for the PIC. You want to test end to end connectivity so you use the software to flip a parallel port bit and verify that the corresponding pin on the programming socket responds properly. > One more thing, if I really screwed up on a circuit, could I fry > the parallel port on the computer or do most systems have protection? Yes you could fry it especially if you connect two output buffers together. That's one of the reasons for the 1K resistor between the '573 output and RB7 on the programming socket. Do take some care because a burnt parallel port on a MB cannot be replaced. > > Here's the reason I'm really posting, mapping the terms listed on the > schematic for the TLVP to the real pins on a 16F628: Pulled up my data sheet and ready to go: > > TLVP 16F628 > "Vdd" Pin 14 "Vdd" Check > "Rb7/Data" Pin 13 "RB7/T1OSI" or Pin 7 "RB1/RX/DT"? * Pin 13. The Data function is actually a programming function and is specified on the programming specifications document (DS30034B) at the bottom of the page. The RB7/RB6 pair is the standard serial programming interface for the entire PIC midrange/highrange families. > "RB6/Clk" Pin 12 "RB6/T1OSO/T1CKI" Yup. > "MCLR/Vpp" Pin 4 "RA5/MCLR/THV" Right. > "RBX/PGM" Pin 10 "RB4/PGM" Correct. > "OSC1/CLKIN" Pin 16 "RA7/OSC1/CLKIN" Yes. Simply ground it on the programming socket so it won't have any chance of oscillating. > "Vss" Pin 5 "Vss" Correct. > > * Pin 7 is described as "USART receive pin/synchronous data I/O", and I've > been using pin 13, that could my problem, but before I pull out the hair I > have left I thought I'd confirm all this. You're already correct. The hardware USART has nothing to do with the standard serial programming interface. So back to the grind. I don't use FPP on a regular basis but I'm almost certain that its Setup/Debug page has the same facilities as picprg2.3d's Config page. Testing is pretty simple: 1) Plug the programmer into the parallel port using a short cable. A cable longer that 2ft will guarantee failure. 2) Fire up the programming software and go to the Config/Setup/Debug page. 3) For each of the programming pins (DATAOUT/CLK/PGM/DATAIN) configure the pin on the page to the corresponding parallel port pin. For example the CLK pin should be configured to pin 3 of the parallel port. 4) Test the pin by using the programming software to turn the pin on and off. Verify the voltage at the corresponding pin on the programmer socket. So again if you were testing the CLK pin you would set it to pin 3, the parallel port pin, on the config/setup/debug page, but you would test pin 12 (CLK) on the actually programming socket. If the voltage on the socket doesn't change when you flip the pin in the software, then you must debug the path from the parallel port, through the HCT573, to the pin and find out why it doesn't change. Possible causes are that you've configured the incorrect parallel port, or that the HCT573 doesn't have power. Verify both. If correct the you need to disconnect the programmer and testing the pins directly on the parallel port and verify that the programming software can in fact control the port. 5) Once you get one pin working, repeat the process for the others. At this point you should be done. Test in picprg2.3d by simply inserting a chip into the programming socket and running picprg2.3d. The first thing it does is autodetect the chip inserted. So if the main page comes up listing the 16F628 as the installed chip, then you know that all of the pins of the programmer are correctly configured and that the chip is in LVP mode. Take another crack at it. It comes a lot faster with practice. I can lash up a TLVP programmer and test it on a breadboard in less than a half hour using $5 US in RadioShack parts (excluding the breadboard). One last caveat: The schematic as drawn doesn't work with the INTRC and INTMCLR because it requires a power cycle to start programming mode. You have to use the schematic listed below the main TLVP schematic for that configuration. BAJ -- http://www.piclist.com hint: The PICList is archived three different ways. See http://www.piclist.com/#archives for details.