Hey, thanks again.

Heres the layout, pretty easy considering I had designed it with eagle anyway (on stripboard), so I just used eagle3d again.

I know that during programming, if the crystal osc starts very quickly it can causing the program counter to 'skip'. At least thats what I've read, so that its programmed with the wrong data in the wrong area's. This really doesn't bother me for this little project, I just don't want to make a nice PCB (or stripboard) in future, only to be restricted to the internal osc. Its weird, it's always worked on stripboard, with or without the crystal actually plugged in during programming! So maybe this is a PICkit2 issue......as it compiles perfectly.

As you can see by the layout, nothing special, just the usual, plus a 2x8 LCD header for debugging. There is a link

Blueteeth

Attached Images

	1350635674.jpg (105.8 KB, 31 views)
	1350635676.jpg (57.3 KB, 26 views)

__________________
Inconsistency is the key to flexibility!

 

Ummm... that is not a crystal, it is a ceramic resonator. Programming is probably using the internal oscillator. You should look up the recommendations for that part and what PIC says about driving it.

Dan

 

Nope, tis a crystal, well, its not shown, but its a 3-way sil socket, centre is gnd, outer two are directly connected to the osc pins, and two caps, both to gnd. I like to keep my options open, so I *could* use a resonator if needs be (probably have to remove the caps though) it was just a test board anyway, for 18-pin pics, stripboard layout, and techniques.

So I've been pluging in crystals. The addition of a 'Gnd' socket in the middle makes no difference as far as I'm concerned. So my guess is, its the socket, or just a crappy layout, it is rather crowded there.
Blueteeth

__________________
Inconsistency is the key to flexibility!

 

Well I'll take your word for it then. I have only ever seen resonators in the package in your piccy, unless I am looking at the wrong thing.

Dan

 

I once had problems with a PIC (on a PCB) which was doing some strange erratic and unpredictable things.

The problem turned out to be a couple of unused inputs which I had left floating.
Grounding the inputs via a 10k resistor cured the erratic behaviour.

JimB

__________________
Experience is directly proportional to the value of the equipment ruined.

 

Hi Blueteeth,
When you clearly mentioned in your 1st post, that the int osc is used, i fail to understand what we are discussing around crystal or resonator? you may vwery well remove those components around Osc pins and go ahead of your program--

__________________
Regards,
Sarma.

 

Because I'm curious as to why it doesn't work, with an external osc, on that board, when external osc's with the exact same PIC work on other boards. And I don't like to be restricted to only a few clock frequencies, why should I? The internal driver for using an external crystal is a basic function of the chip itself.

I mean, I could just let it go, and happily use the internal osc for all apps on that board (which I might add, I use to test many programs, including those that require strange crystal frequencies), but what if I design another board and this happens again? If I'm doing something hideously wrong, I like to know about it, it'll save time and money in the future. That said, I imagine it'll be just dandy on a nice expensive FR4 professionally made board. Many have said they've had no trouble programming/running a PIC, on stripboard with any crystal, so I took the problem here.

Jim B. I haven't had that problem with breadboarding...usually have PORTA as all inputs. But...I will definately try setting all unconnected 'inputs' to outputs, or tying them to ground, I've heard of this before, on another forum someone mentioned it caused them weeks of stress. So thankyou

cadstarsucks. I don't think you're looking at the wrong thing, because there isn't a resonator, or a crystal in the picture Just a basic sil socket which a crystal/res will be plugged into. Its my fault really, with my custom library in eagle, the 'symbol' for that component is a xtal symbol. Can't say I use resonators at all, as xtal oscialltors have (almost) always worked fine wwith any PIC.

I wish I had an oscilloscope.

Blueteeth

__________________
Inconsistency is the key to flexibility!

 

If the external crystal doesn't work, then you're doing something wrong (or have a duff component), there are no problems with micro-controllers and crystals on properly designed stripboard or PCB's. Many people also use them with no problems on breadboards, and even with long leads to the crystal - but I wouldn't advise doing either of those!.

The tracks on your PCB layout are plenty short enough, and assuming it's all connected correctly (which I haven't checked) should work fine.

If you do get hold of a scope though, make sure you use a x10 probe, or the capacitance of the scope will probably stop it oscillating anyway.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk

 

Cheers for the input nigel, I think I'm going to do what I should have done in the first place, replace those caps. They're cheap ceramic, so probably not the best choice, and often wildly off-value. And yes, I've checked and double checked the layout, its hard to see in my eagle layout, because the gnd's of the caps share a hole, and sorry cadstarsucks....you're right, in that eagle3d pic, its a 3-pin header. It should have been a socket, and the yellow things are the caps, so just imagine that the crystal is connected to the two outside pins, with the middle connected to gnd.

As I said, it sohuldn't really be a problem, but its bugging me ya know? Also, I'm not completely sure why it wouldn't program correctly, sure, a duff crystal would prevent a PIC from running, but unless the osc starts up instantly, it shouldn't interfere with programming...note, my old JDM programmer doesn't cut it either, same error 'verify failed' and quite a few bad bytes.

Cheers guys, I'll let you know what I find.

Blueteeth

__________________
Inconsistency is the key to flexibility!

 

OK, here we go again.......

I've just spent the past two hours (I'm ill, off work, got time to waste) attempting to read, write and erase PIC's on this board. I updated the PICkit2 firmware, and host software to the latest versions.

With the old pickit2 firmwares, every time I read the chip on the board, I got different data every time....comms issue there. I could erase the chip, but heres the real stumper....I couldn't write any hex file to the PIC *>unless<* the code used the internal oscillator! It ran the program fine (LCD test routine). I midofied the working program, simply by changing the config header to '_XT_OSC' - no go. Program verification failed 9 times. This also happened on breadboard.

Turns out it was the only thing I didn't thing of: a really weird PIC. Put in a 628A, new 819, 877A...all worked fine.
This particular 16F819 doesn't want to use a crystal osc, and refuses to be programmed to use it. I am now more confused than ever, its had some usage in the past few months, but I couldn't have used up all the write cycles..could I? Once again, shoddy stripboard layout is vindicated!

So, there we go, problem solved, I'm still peeved at microchip though, good thing I have a lot of their devices.

Blueteeth

__________________
Inconsistency is the key to flexibility!

 

Who knows you could have killed the internal driver. God's know I've fried more than one I/O pin on a micro controller. Have you tried it on a new 16F819? Try slowing down your programming cycle to the slowest possible rate your programmer allows, you may just be having timeing issues with the one chip.

__________________

 

Hmm good possibility I have inded 'blown the xtal driver'. But that still doesn't explain why it wouldn't program. I've programmed plenty of PIC's in a JDM, or with a simple ICSP setup with a PICkit2 (only ICSP pins connected) and it worked, whether the program used an external crystal or not.

I do'nt tihnk the PICkit allows slower timing, my JDM however, does. ..something to try there, thanks.

And yes, a brand spanking new 819 works just fine. I guess the 'old' one has been through the wars and I zapped the xtal driver, and possibly some other 'organs' is needs to do what I tell it too >.<

Cheers man,

Blueteeth

__________________
Inconsistency is the key to flexibility!

 

In the PicKit2 programming application, go to Tools and then uncheck where it says Fast Programming.

 

But the chip still needs to be getting a clock to be programmed, it's needed for flash read/write timeing I think. If your Xtal pin is not working properly then there's no clock for the micro to even start up to enter programming mode. You may be able to set fuses or run run a chip erase cycle without the chip getting a clock. I'd mark the chip so that you know you can only ever use the internal osc. You may still be able to run it using an external logic level clock, but it just sounds like the crystal driver was fried.

__________________

 

No, exactly the opposite - the clock must NOT be running, or you can't enter programming mode, which is a slight problem with the original InchWorm as it didn't switch Vdd.

If the clock doesn't run, and you can't program it, it sounds like it's been seriously fried! - which takes some doing really!.

__________________
PIC programmer software, and PIC Tutorials at:
http://www.winpicprog.co.uk