Has anyone noticed problems with the PIC16F628A?

Hi to all,

Has anyone had trouble with getting 16F628A programs to work properly?

I have 4 of them and I just spent 2 days trying to denug a program that I wrote, which never worked properly when I burnt to the 628A.

I even tried different 628s and got different results with each one! I then tried a 4th 628 and bingo! Everything working - 2 days wasted!

Have I got the only 4 628s that are faulty? There must be more? I realise that Microchip would not advertise the problem if they knew about it but there must be people out there wasting time as I did and thinking they were going mad!

Anyone else have a similar story?

Al

PS I will never use another 628 and if I hadn't invested so much time in PICs I would switch to Atmel!

I used two of these and all problems I run across were my fault.

4 out of 5? Nooooooooooot likley.

Some background might help, perhaps there's a programming flag that you changed last that made the last unit work, have you gone back to any other old one's to try to reprogram them? Another possibility is a clock speed mismatch in re-programming, if you set the wrong fuse or clock on any micro controller you can have extreme difficulty accessing it again..

I recommend Atmel myself but I wouldn't give up on PICs based on what you've said, there's nearly a 99% chance that it's something you did accidentally or otherwise without realizing it that caused the chips to act they way they are, there's a decent chance there is nothing wrong with the chips simply a clock mismatch would be the first thing to investigate.

Take the programmer you're using and slow it's programming rate down to the absolutely lowest it can possibly support, and even if you don't think you've disabled an internal oscilator apply a clock of at least 4 times the programming rate to the Xtal2 pin.

From personal experience I had two ISP programmers that I pronounced dead, as well at 3 chips that I after realizing what had been done to them was able to get both ISP programmers functioning again and all but 1 chip was 'revived' the 1 chip that I tossed only had a single bad I/O line (that I killed) I just got rid of it because I have plenty of devices.

If you let us know the issues.... We can fathom out if its a small tolerance problem or something that people need warned about..

The problem is your programmer.
Try a USB programmer such as PICKit-2.

hi Al,
You have my address, feel free to post to me the 4 suspect 16F628A's and will test them for you.

I have used 628A's without any problems

Regards
Eric

I would suggest you're most likely doing something wrong, PIC's are extremely reliable and survive a lot of abuse.

However, you don't give any clue as to what you problem actually is?.

Hi Guys,

Firstly I am using my Easypic5 programmer which is USB and up to now been reliable.

I started off using MikroBasic and got so as I was reasonable with it, nothing too complex though, then I tried PicBasicPro and found it more friendly to use with just a small amount of bother pairing PBPs MicroStudio to my on board PicFlash programmer, but I succeeded in the end.

Now yesterday I was trying to flash the 628As with weird results - sometimes parts of the programs worked and next time a different part would work and the original fault be gone! When setting a pin high and measuring that with a different pin, the pin I set high would be pulled low just by my reading it.

I thought yesterday that it was faulty 628s but then I tried my prog on a 16F877A which had a working program from some time ago on it and it still ran ok. After flashing that with my new program it didn't work, and also the next Pic I tried - a 627A - did not work and reported that the pic was a 12F508.

I went back to MikrBasic and loaded an example program and it worked, then tried again and it failed, this was on my 877A.

I am now baffled as to what is happening. I do have a Pickit3 which I could try to use if it were not for the fact I would have to use MPlab, which I have tried and tried to get to grips with but sadly failed every time, I just don't get it at all!

Anyway I would be glad of any ideas on the matter and thanks Eric, but you may be getting more that the 628As, might have to post you all the lot, laptop and all, hehehe.

Thanks again guys, Al

PS isn't there a simple programmer for Pickit that I can just load a Hex file into and flash without all the MPlab project stuff, it really does baffle me!

bigal_scorpio said:

I do have a Pickit3 which I could try to use if it were not for the fact I would have to use MPlab

Click to expand...

Fair comment Al, have a look at this link for a standalone GUI.
https://www.microchip.com/forums/m525698.aspx

bigal_scorpio said:

PS isn't there a simple programmer for Pickit that I can just load a Hex file into and flash without all the MPlab project stuff, it really does baffle me!

Click to expand...

There's the PICKit3 software that comes with it - simply select the PIC you're using, load the HEX file, and press 'write'.

Just use MPASM.

colin55 said:

Just use MPASM.

Click to expand...

Not a very helpful suggestion when he's wanting to use a programmer.

PS isn't there a simple programmer for Pickit that I can just load a Hex file into

Click to expand...

Just use Notepad, MPASM and PICkit-2

colin55 said:

Sorry, Just use MPASM and PICkit-2

Click to expand...

You're not reading the posts in this thread are you?

He has a PICKit3, so would need that's software, not the PICKit2's, and if he wanted to use an assembler it would be MPASMWIN anyway, and not MPASM

Hi Guys,

Took all the suggestions into my "ram". Had some limited success, well, things got worse for a while where I couldn't get anything to work at all. The PIcs I originally tried and failed with got so they would not even accept a program, even though the assembler went through the motions.

Then as I persevered I got one to program with the MikroE Picflash and then it seemed to be back to its programmable state as it should be, but with the same strange results on the odd pin which is when I lets say make PORTA.0 high and check its state with PORTA.2 it seems to pull PORTA.0 down to 0v (well the LED on PORTA.0 does not stay lit).

So I'm basically back to where we started this thread. What could cause this? Is it faulty pics? Bear in mind if I program a 16F630 with the same program with just the LCD code commented out due to lack of pins, then the program works fine! Then the LED that is high on that same pin lights and stays lit while the other pin is reading its state. Whats going on?

Any suggestions folks?

Thanks Al

bigal_scorpio said:

Hi Guys,

Took all the suggestions into my "ram". Had some limited success, well, things got worse for a while where I couldn't get anything to work at all. The PIcs I originally tried and failed with got so they would not even accept a program, even though the assembler went through the motions.

Then as I persevered I got one to program with the MikroE Picflash and then it seemed to be back to its programmable state as it should be, but with the same strange results on the odd pin which is when I lets say make PORTA.0 high and check its state with PORTA.2 it seems to pull PORTA.0 down to 0v (well the LED on PORTA.0 does not stay lit).

So I'm basically back to where we started this thread. What could cause this? Is it faulty pics? Bear in mind if I program a 16F630 with the same program with just the LCD code commented out due to lack of pins, then the program works fine! Then the LED that is high on that same pin lights and stays lit while the other pin is reading its state. Whats going on?

Any suggestions folks?

Click to expand...

Try programming them with your PICKit3 - it sounds like you 'may' have set internal oscillator, and MCLR as I/O - depending on your programmer and target hardware this may mean you can't reprogram them until you connect them in a suitable configuration.

Other than that, hardware faults and software faults.

bigal_scorpio said:

...
but with the same strange results on the odd pin which is when I lets say make PORTA.0 high and check its state with PORTA.2 it seems to pull PORTA.0 down to 0v (well the LED on PORTA.0 does not stay lit).
...
Any suggestions folks?

Click to expand...

Hi Al, I don't use the PICkit3 programmer but have used the MikroElektronika PICflash which has always been very reliable for me.

The symptom above sounds very much like PORTA.2 is an OUTPUT so it is "pulling PORTA.0 down".

When (in your case IF) you join conflicting output pins like that it can cause all sorts of weird symptoms including hangs, program resets and generally weird behaviour.

I would suggest you check your code very carefully for the TRISA stuff or any peripherals etc that might set port pins to outputs. If needed you can write some simple test code to test the PORTA pins, ie set all pins HI for a second then LO for a second, that will show if they are outputs on LEDs or a voltmeter.

Also, you should check hardware for shorts or wrong-connected pins.

Why not post your code you may have some thing set your missing and picbasic pro is that what you using here I think you said you us it.

Here some thing to look at

The RA2 pin will also function as the output for the
voltage reference. When in this mode, the VREF pin is a
very high-impedance output. The user must configure
TRISA<2> bit as an input and use high-impedance
loads.

Click to expand...

Nigel Goodwin said:

Try programming them with your PICKit3 - it sounds like you 'may' have set internal oscillator, and MCLR as I/O - depending on your programmer and target hardware this may mean you can't reprogram them until you connect them in a suitable configuration.

Click to expand...

Hi to all,

Nigel, it seems that you may well be right with that!

I managed to reprogram one of the 628s with the Pickit3, but I don't know what I did, and can't seem to repeat it!

One thing the Pickit does is require me to set the config bits manually and I am not used to that. I can't figure out the method used to do it, with all the little boxes that don't say MCLRE on or BODEN off.

After looking at the datasheet for the 628A it is as clear as mud to me. They seem to be trying to confound people even to the degree of saying that a "1" in some address bits means its off and would mean its on in another.

Baffled again I'm affraid. Al

Edit. I almost forgot to say that when I got a 628 to build and flash correctly the program actually worked flawlessly. Now I have another 3 628As that I can't use until I can recreate the thing I accidentally did with the one that is now OK.

Looks like Eric may be getting a small package!

Hi to all,

Ok so I now just about understand the way Pickit3 does the config bits. I still think the Pic datasheets are vague on some points though, like where it states that if MCLRE is enabled when using INTOSC it will disable the oscillator.

Besides the wierd stuff can anyone please tell me a way of restoring my 628As to a usable condition? I have tried and tried all the ideas I can think of such as Erasing and programming with different config bits set and even tried them with both my PicFlash and Pickit3 programmers all to no avail! What do I need to do to get them up and running and willing to accept programming?

My Pickit3 reports"Programming device...Program Failed" then "Address 0x0, read 0x3FFF, Expected 0x1B2", when I try to program. I don't know if this helps to clarify anything?

Help would be much appreciated as I now have only a 16F88 pic that I can use for anything needing 18 pins apart from 3 useless 628As!

If in future I do ever get any more 628As should I treat them as OTP products? Or just steer clear of them?

If I should keep away from them can anyone reccommend a good substitute 18 pin device, cheap as possible.

Thanks again. Al