PIC + stripboard = no go.

[mvs sarma]

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

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--

 

[Blueteeth]

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--

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

 

[Nigel Goodwin]

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.

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.

 

[Blueteeth]

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

 

[Blueteeth]

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

 

[Sceadwian]

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.

 

[Blueteeth]

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

 

[TekNoir]

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

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

 

[Sceadwian]

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.

 

[Nigel Goodwin]

But the chip still needs to be getting a clock to be programmed, it's needed for flash read/write timeing I think.

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!.

 

[Blueteeth]

Hmm, well, you've convinced me I honestly thought that programming timing was completely controlled by the programmer...why does the JDM programmer work then? (no ICSP, no osc, just a socket)

In all my testing I also snapped of a leg or two, so I'll just permenantly solder it to a small bit of stripboard, and mark it as suggested. useful chip though, 8Mhz internal osc, SPI, ADC and host of other goodies.

Blueteeth

Edit: OK so I spoke too soon...its not even being recognised now...its picked up as 'connected' and being a 819, but thats all she wrote I'll add it to the pile of 'things to recieve high voltage'

 

[Nigel Goodwin]

In all my testing I also snapped of a leg or two

You should do what I do, I fit my working PIC's in turned pin sockets, then plug that into a normal socket on the board. The turned pin socket has nice straight pins so plugs and unplugs easily, and if you break a pin off it you can just replace the socket. In all my years (in double figures) of PIC programming I've never broken a pin off a PIC, or even off one of the turned pin sockets!.

I'd like to claim it was my idea, but Don McKenzie (Dontronics) used to do it as well!.

 

[3v0]

During development where I need to remove the PIC I also use sockets to protect the pins. But I use same cheap tin plated sockets that I use in most of my work. They do not work in some breadboards but work well when plugged into other sockets.

 

[mvs sarma]

You should do what I do, I fit my working PIC's in turned pin sockets, then plug that into a normal socket on the board. The turned pin socket has nice straight pins so plugs and unplugs easily, and if you break a pin off it you can just replace the socket. In all my years (in double figures) of PIC programming I've never broken a pin off a PIC, or even off one of the turned pin sockets!.

I'd like to claim it was my idea, but Don McKenzie (Dontronics) used to do it as well!.

I have a different experience with turned pin sockets-- when I try to remove the IC, the inserted shaped coller comes out of the turned pin and holds with IC pin and later falls off
and if we loose site of this we will be forced to replace that pin. and if more collers are missing, then the base itself.

 

[Nigel Goodwin]

You don't take the IC out of the turned pin socket, it becomes a permanent part of it - but you must be using some cheap and nasty sockets if they fall apart?.

 

[Blueteeth]

I always use sockets, but that isn't really what this thread is about, I only broke the pins through rough handling and constant plugging/unplugging the PIC in and out of various breadboards/programmers. Still usable, but an IC with broken pins is better off being soldered directly to a PCB, that way you can use little wires to solder to the broken pins. Its only a 819 anyway, 90p worth of hardware. And it'll help me work out just what is the most convenient 'stripboard -add-on' to a breadboard. - still can't believe how odd its behaving, no biggie, got 6 16F88's here looking at me funny, time to put them to work.

Blueteeth

 

[3v0]

I always use sockets, but that isn't really what this thread is about, I only broke the pins through rough handling and constant plugging/unplugging the PIC in and out of various breadboards/programmers.
Blueteeth

When you are going to be moving a chip around protect its pins by placing it in a sacrificial socket. That is to say you plug the chip in the sacrificial socket, then plug that unit into your breadboard or PCB socket.

If you break a pin just replace the sacrificial socket and you are back in the game.