![]() |
![]() |
![]() |
|
|
|||||||
| Micro Controllers Discuss all aspects of micro controllers - building them, coding them, etc. All controllers are welcome - PIC, BASIC, Z8 Encore!, etc. |
|
|
Thread Tools | Display Modes |
|
|
(permalink) |
|
I'm working through some of Nigel's tutorials, and trying to use the Inchworm ICD2 to program the 16F628A devices. However, Nigel's tutorials suggest using:
__config 0x3D18 I think that will cause problems with the Inchworm because of _MCLR and setting the internal oscillator. Am I correct? I tried setting it to: __Config 0x3D38 It programmed once correctly, but now it seems totally broken. Reprogramming attempts give me: ICD0161: Verify failed (MemType = Program, Address = 0x7, Expected Val = 0x1683, Val Read = 0x1003) ICD0275: Programming failed. Did I blow these units? Any suggestion for the proper configuration bits here? This is pretty tricky for a newcomer to try to use Nigel's lessons and an Inchworm programmer. Maybe I should've stuck to an easier programmer for my first try at this... -LP |
|
|
|
|
|
|
(permalink) | ||
|
Quote:
Quote:
__________________
--- The days of the digital watch are numbered. --- |
|||
|
|
|
|
|
(permalink) |
|
I think I see what you're saying about pull-downs and pull-ups (and yes, I was trying to program in-circuit).
However, even just trying to program the devices alone again are giving me problems. I'm getting: ICD0161: Verify failed (MemType = Program, Address = 0x7, Expected Val = 0x1683, Val Read = 0x1003) ICD0275: Programming failed. Seems that I was able to write to these once, but now I'm having problems. Any chance the device is at fault? The 16F628A is flash, right? Should be programmable multiple times? Thoughts? -LP |
|
|
|
|
|
|
(permalink) |
|
I would have thought the PIC being faulty is EXTREMELY unlikely, more likely is a problem with the ICSP - which my tutorials boards were never designed to do. What changes have you made to the board?.
You might consider using the 16F876 board?, and I've got a circuit for that modified for InchWorm. |
|
|
|
|
|
|
(permalink) |
|
Nigel: Thanks for the comment. Made me go back and double check things and I think I found the problem (though I still have some questions). My programming circuit was incorrect. I used a diode/resistor between VPP/GND, not between VPP/VDD. It worked for a few programs, but now I think the parts are dead. Even hooking it in the correct configuration wasn't able to bring them back to life. Thoughts anyone?
Additionally, regarding Inchworm and your projects: Other than the configuration bits, I'm not sure what else is different (and why it shouldn't work). My configuration is the part on a project board, with 5 signals (VSS/VDD/VPP/PGD/PGC) coming from Inchworm. I've got a diode/resistor between VPP/VDD for programming. Additionally, I simply wired 4 1K -LP |
|
|
|
|
|
|
(permalink) |
|
Sorry to dig up an old thread but I've just tried Nigel's blink a LED program and I also get the same errors you got with a inchworm. If I use __CONFIG 0x3F34 it programs fine.
I've done some fiddeling with the bits and it comes down to setting bit5 to 0 causes it to fail. bit 5: MCLRE: RA5/MCLR pin function select 1 = RA5/MCLR pin function is MCLR 0 = RA5/MCLR pin function is digital Input, MCLR internally tied to VDD |
|
|
|
|
|
|
(permalink) |
|
That's right, InchWorm works by controlling MCLR, if MCLR is disabled in the config fuses you won't be able to program it after the first time - you require a programmer that switches the +5V rail, so you can take control of MCLR before the PIC starts running.
|
|
|
|
|
|
|
(permalink) |
|
Thanks for clearing it up. I've always wondered what all those config bits do
|
|
|
|
|