On Sun, Oct 28, 2007 at 10:13:20PM -0400, Detrick Merz wrote: > Warning: I am new. I have searched the archives, and read much > information looking for answers. I successfully programmed a 16F84A, > once, a few years ago, and it did some LED blinking, but much time > (and lost memory) has passed since then. > > Now that that's out of the way... > > I have been going through the "Elmer 160" course, and I am at the > point where it's time to start putting code onto a chip, and making it > do something to interact with the real world. This is exciting! The > not so exciting part, of course, is failing to get the code onto the > PIC. Heeding the advice of just about everything I have read, I have > been working with a 16F628A intead of the 'F84. Good. > I have built one of BAJ's THVP's, but have not quite had luck with it > yet, at least not using FPP to talk through it to a PIC. FPP is older than dirt. I probably should have pulled it from the page. Nigel Goodwin's WinPicProg is probably a better choice: http://www.winpicprog.co.uk/ > Using a > multimeter, and twiddling with the test knobs within FPP, the THVP > seems to be wired right. It wasn't, at first, and the multimeter > showed me this. Having fixed the issue, I see all the pins go high > and low as expected. Trying to push code to the PIC through FPP > results *immediately* in FPP telling me "Failed to program code!". It > does claim to successfully erase the PIC, and read the PIC (comes back > with "-- Blank --"). The archives showed me that Konstantin had had > this come up before... I hope I don't become a Konstantin (no > offense)! Anyway, the three bits I got out of the archives were to > check the programmer with a multimeter (done, checks out), to make > sure that giveio.sys is in and working (should be, I can twiddle the > test knobs in FPP and check with a multimeter) and to use a shorter > cable. The THVP has the long cable termination bits in it, but just > for S&G's I jacked the programmer directly into my parallel port (no > cable). It acts the same way. FPP has some default pinouts for the > TLVP, which I tried selecting and inverting MCLR, and they check out > equally well with the multimeter but show no success when programming. > It looks like the FPP config for TLVP is nearly identical to what is > needed for THVP.. just remove PGM (unnecessary for THVP), and invert > MCLR. An even more interesting bit, is that FPP shows the same > programming results when I disconnect the THVP: fails to program > immediately, but also successfully erases and reads (or so it claims > anyway). That last part means that something else is going on. I'm glad that you shortened the cable. Also I've had mixed results with the AC termination. The best results I've gotten recently are by using a unshielded twisted pair network cable. Works consistently up to about 5ft. > So, now, to rule out more bits (read: Windows), I feel I would like to > try to program the pic from my linux box. Since BAJ is (according to > the archives) using 'picprg' under linux, and the THVP is his twist on > the Tait design, I figure it's a good mix to try. I have picprg3.0 all > nicely compiled, installed and not complaining about /dev/lp0. > picprg3.0 claims it can dump code onto all PICs, which at the least I > would hope would cover my 'F628A. When I start picprg, I go into it's > config settings and set it to talk to the right parallel port pins for > the THVP (inverting MCLR too). When you start picprg after configuration does it pick up with programmer and the part? picprg3.0 is configured to autodetect the chip. I find that it's great for debugging connectivity without having to dump a hex file first. If it doesn't autodetect the chip, then nothing else is going to work. You need to recheck your configuration. > Having done that, I load a very simple > inhx8m style .hex file created by mplab. It is after this that I am > bothered (discouraged from trying to put code on the PIC), and here is > why: > > My config line in the .asm is as follows: > > __config _HS_OSC & _WDT_OFF & _PWRTE_ON & _CP_OFF & _LVP_OFF > > picprg seems pretty fancy, in that it reads the config bits, and > displays them across the top for you in something human readable (not > just "3F62"). When I start it up, and have no .hex loaded, it says: > > CLOCK: RC PIC RAM: 0xc00 CP: OFF WD: ON PU: ON > > I load my .hex, and it changes: > > CLOCK: HS PIC RAM: 0xc00 CP: ON WD: OFF PU: OFF > > Wait, WHAT?! I said "_CP_OFF" and "_PWRTE_ON"... why does this show > the opposite? It did pick up on my using _HS_OSC instead of RC, so > it's figured something out, but why did it seem to get CP and PU > wrong? Programmer (that would be me) error? I'd have to go and take a look at the code. > > To try to troubleshoot this a bit more, I changed the .asm to reflect > an 'F84, since picprg was originally written only to program them > (well, 'C84's anyway...). I changed the config bits several times > within the 'F84 .asm, recompiling the .hex, and loading it into > picprg. Each time, picprg got the config bits right for the 'F84. > Maybe it's display across the top is not up to date with displaying > config bits for PIC's other than the '84, and I should trust that it > will push the right code (including config bits) to the PIC, > regardless of what it shows across the top? That's a good bet. I'm masking off the bits to display them. Maybe I got the mask wrong. You can check the configuration string yourself in main.c > I did learn that I need to manually update .picprgrc and set PIC_size > for whatever type of PIC I'm trying to program at the moment (I might > wrap a shellscript around launching picprog to ask/remind me of this). > That should take care of correcting "PIC RAM: 0xc00." I just don't > feel comfortable asking it to write this stuff out to the PIC until I > understand why it seems to be reporting config bits incorrectly. Again it's probably programmer error. I don't even remember if I had 16F628 handy at the time I was rewriting that piece of code. > > Thoughts? Only two. Did you program the chip? Did it work? I'm here so you can feel free to reply back. I'm so sorry I had to shut down my forum because it was being spammed. BAJ -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist