On 10/29/07, Byron Jeff wrote: >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/ Pulled it down, installed the driver, fired it up. It reads some of my new PIC's (2 'F84As and 1 'F628A), and reports back that everything is all 0's (not 3FFF's, all 0000), including config bits. When I try even changing one config bit, then pushing a "blank" config back, except for the changed config bit, it reports like it's doing a lot of work (writing program memory, writing eeprom...), then fails when blowing config fuses onto the chip. My guess is it's not really getting any feedback from the write, instead it's seeing the ACK line stay low perhaps, and reading that as all zeros. It gives me somewhere to start looking anyway (although, with a multimeter and FPP, the ACK line switched every time I flipped lpt pin2 high and low). I must say, though, I like the feeling of WinPicProg much better than FPP.. it gives a bit better feedback to the user! Maybe I'll even buy a programmer off of Dontronics, and muck with the THVP in the background :) >> 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. Ever any trouble with it connected directly to a parallel port (no cable)? I'll try to make up a UTP Cat5e cable, I have spools of that. Maybe tomorrow.. time is short tonight :) >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. No, but I'm not entirely sure you and I are talking about the same picprg3.0. We might be, but I'm not sure. This one claims across the top: "DROS PIC Programmer by Luke S. Cole, originally by Brian C. Lane" You don't look like either of those people, unless you've changed your names. I pulled my copy from http://cole.homedns.org/picprg.php >> Thoughts? >Only two. Did you program the chip? Did it work? I tried. Sadly, no, not with an 'F628A or an 'F84A in the socket (yes, I changed the underlying code, and all it did was a loop calling itself). Example output trying to write to the 'F84A using PICPrg: =-=-=-=-=Data in (pc) RAM-=-=-=-=-=-=-=-=-=-=-=-=-=-= DROS PIC Programmer by Luke S. Cole, originally by Brian C. Lane CLOCK: HS PIC RAM: 0x400 CP: OFF WD: OFF PU: OFF 0000: 2800 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF 3FFF =-=-=-=Programming (obviously?)=-=-=-=-=-=-=-=-=-=-=-=-=-=-= CLOCK: HS PIC RAM: 0x400 CP: OFF WD: OFF PU: OFF Programming PIC 0x2000: 0x3fff 0000: 3FFF != 2800 =-=-=-=-=-=-Verifying (or trying anyway)=-=-=-=-=-=-=-=-= CLOCK: HS PIC RAM: 0x400 CP: OFF WD: OFF PU: OFF Verifying PIC 0x2006: 0x3fff 0000: 3FFF != 2800 2007: 3FFF != 3FF2 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> > > I have been going through the "Elmer 160" course,... >> > >> > Generaly pretty good, even if they uses the F84A... :-) >> >> They do, but I've been swapping in the 'F628A instead as I go through it. > >That's fine as long as you understand that it's critical to grasp the use >of hardware periperals. The major problem I had with that course is that it >bit banged everything (due to the 16F84). I'll certainly keep that in mind, but I feel (at least for me) that bit banging is a good way to start. Once I understand how something works when bit banged, I always seem to better grasp how the higher level functions do the same thing. Maybe it's just the way I learn, but I always seem to have a lot more trouble with things until I can get under the covers and figure out what makes it tick. >Nigel Goodwin's course picked up with a 16F877 IIRC. Much better platform >to learn from. I'll plan to look at that one next... I think I'd like to complete the Elmer160 course first, even if it isn't ideal. It seems well written, and I feel like I've learned a lot from it so far. >No worries. All CP set on means is that you have to do a full code/config >erasure before you can reprogram the part. Also rest assured that picprg >doesn't change any of the config bits. You're probably seeing a display >error only. As a n00b, I have a gripe here. Perhaps this isn't the most appropriate forum for it, but maybe starting it here will result in something changing. On piclist.com, under the "Beginner's Checklist," I find the following: "DO NOT ENABLE CODE PROTECTION! No, it can't be undone. You will have to replace the chip. Read the documentation on your programmer to figure out how to avoid this." This sounds pretty ominous. Now, I find out, it's not a big deal... it *can* be undone. I *don't* have to replace the chip. Even more, I don't have to fret over having it set "wrong," I just won't be able to read the code back. Can someone change this text, or did I miss the boat? Can we go through and start cleaning out all the broken links, or links to bad data (like references to older version of things like picprg)? How about all the references to the 'F84? If it is so hated these days, why not point beginners directly to the 'F682, or the 'F877, or the next best thing? I know, it's all too much to keep up with, but can we start now? Maybe the list will have fewer annoying questions like mine! >> > No local processor. Barely more than just a parallel cable. >> >> OK. You will see a few supporters of that kind of >> "programmer", and many opponents here... :-) >And somewhat rightfully so. No smarts homebrews generally require a measure >of patience that frustrates many that just want to get to it. the Trivial >Programmer series is deliberately a junkbox programmer. Patience I have. Even if I don't, I still feel that the no smarts "programmer" is the way to get started, at least for some. For me, even in a non-functional state, I have learned quite a bit about PICs just trying to get it to work. I've found documentation (like AN589) I may have never come across before. I've been able to perform basic troubleshooting on a simple simple device... if I were having trouble with a Wisp628 or a PICallW, it surely would take a lot more to diagnose... there's just more going on (of course, maybe those have a higher rate of success out of the box, so debug happens infrequently)! Simple can be frustrating, sure, but there's a ton of learning in the process. >Personally I'm a fan of bootloaders. That way the programmer is on the >target and you can choose the interface that works for you along with >choosing the interface pins that works for you too. Wouter has developed >excellent 1 pin, 1/2 pin, and we at least designed a true zero pin >bootloader, though I don't think anyone has gotten around to implementing >it yet. USB to serial cables are plentiful and inexpensive, so serial >interfaces are still easy to do as long as you don't need EIA-232 voltages. Wayyy over my head. I've taken cursory glances at bootloaders. I think I have the basic concept, but I still feel like, as a beginner, I should start off doing things the "hard way." Then, I will get a better understanding of what really does what, and have a more solid foundation to aid in my future troubleshooting. Thanks for everything so far, from everyone... I'm going to plug away with a few more things (cat5 cable, rooting through the junk box for another latch IC and rigging up a new "programmer" on a breadboard, sleeping). Above all, it's great to have joined a forum, asked some questions as a new person, and not been flooded with RTFM responses.. instead, it's a warm welcome, with helpful advice, in a cheerful note! -detrick -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist