Trouble With my PIC Programmer

"Brick" schreef in bericht news: snipped-for-privacy@g10g2000cwb.googlegroups.com...

Brick,

Do you have the available doc? See:

At first glance I see the firmware revision that should be 2.0.0. or greater, it mentions an adapter socket to be required for programming 10F2xx devices. Maybe some other details have to be taken into account. Does the programmer indentify the device correctly? What about checking out with a

12F50x device? The programmer might be defective but I'd bet on a wrong connection or something like that.

petrus bitbyter

Yeah, I read through carefully and it said fairly explicitly that the adapter only connected the pins and required no passive or active components. It lists which pins on the programmer attaches to which pins on the chip. It was a little bit vague as to which direction the count ran on the programmer but I've tried it both ways with different chips. At first I was using the baseline flash specific software and it didn't mention whether the device was recognized. I then realized that I could use the programmer with pickit too and it said "insert device." It might be that the pickit software doesn't know how to recognize the

10f series and this is why they included the baseline specific version of pickit. The firmware version is read as 2.0.2 so this seems fine.

Thanks for taking the time to look into it.

I had a problem with the PIC16F627A. It turns out the 'A' version is not program compatable with the non-A part! I got all zero's all the time until I updated my programming software for the newer part.

Luhan

Oh and unfortunately I don't have anything other than 10f202's to check it with.

Hmmm that's interesting Luhan. I checked on microchip's website and the newest version is 1.3 while I only have 1.2. Hopefully a software update will fix my problem too.

It seems to be detecting the programmer properly. There's no walwart needed for this little guy. I am using a laptop, my usb port says that it allows a max current of 500mA. Would I really need much more than this?

The only adapter information is for the sot-23 package. I assumed that the dip would be the same (as in gp0 would connect to the same programmer pin for both chips). Is there any chance that the programming would require different pin connections for the dip chip? It seems strange if it would since no information is available about that.

try to unplug the programmer and attempt a write. if it still thinks its there then you have also software issues. if it detects it not being there then maybe your voltage output on the USB is low? that is if your using a USB unit with no helper supply ? P.S. if you are using a wallwart!, may sure it has the correct output. i had a problem with the AVR programmer in this respect, i had to use a 1200 ma at 12 VDC regulated . the kit did not supply a wallwart but did give you a cable to connect to some 12 volt DC source. if your using a LapTop check your power level settings for the USB port.

--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

hmm,. i have the PicStart2+ i think they call it, its in a little black case with a small header on it that connects the carrier board. it is USB also, it works fine for me how ever! i do know that some laptops do not generate the required voltages needed! have you tried this on a Desktop ?

--
Real Programmers Do things like this.
http://webpages.charter.net/jamie_5

"Brick" schreef in bericht news: snipped-for-privacy@i39g2000cwa.googlegroups.com...

Hmm... Sot-23 is six pins and dip eight pins. Pinnumbers and -positions differ widely with respect to the pinfunctions. They also differ widely form the 12F62x. I think that's the reason you need an adapter. It reconfigures the pinnumbers with respect to the functions. Taken that into account, the hardware for 10F--- programmer does not differ from the 12F---. But the programming algorithems differ so the software has to differ too. I know because I did program a 10F200 that way. So if you're sure you made the right connections, the only thing I can think about is contacting your supplier.

petrus bitbyter

Also some radical differences between respective FLASH prog. methodologies of

16F877 and 16F877A .... much to my surprise and annoyance. I learned this only after repeated prog/verify failures at word 0x0000 of a handful of brand new 16F877A chips. Read the chip; "Chip seems to be erased". Program the chip; ka-boom! Read the chip; "Chip is code protected". Say WHAT? Made no sense. The free programming software I was trying to use wasn't telling me the whole story. Decided to write my own &%$@! programming software! I D/L the latest Flash Prog. Spec. for 16F877, which, it so happened, covered the 877A. Once I'd digested that, the root cause of my problem was clear.

Code protected program memory reads out as zeros, but in my (admittedly limited) experience w/ PICs, the device ID loc. (and user ID locs?) should read as what they actually are, regardless of code protection. So if a programmer/software shows you the actual ID loc. data as zeros, I would tend to suspect the programmer and/or the software that runs it before suspecting the chip. Too, if prog. software reports that it doesn't recognize the PIC and *does*not* report the actual ID data that lead to its conclusion then you know only that something is amiss; you haven't enough diagnostic data to decide, with certainty, whether the PIC, the programmer, the software, or any adapter is at fault.

The 877A prog. s/w I ultimately wrote is very verbose! :-)

-- Michael

Well I figured it out! After many, many hours down the drain I've got it. After checking that the software, firmware, and my adapter were all up to speed (over and over again) I moved on to the hardware. I tested all of the lines from the programmer with an oscilliscope and they were all acting as the programming specifications would have me expect. As soon as I connected them to the chip, however, the lines became very ugly. I figured that this meant that the chip had been ruined somehow so then I tried a new chip. This went on a few times before I was about to give up all hope. Then I glanced up from the programmer and noticed the antistatic tray that every single one of these chips had been coming from. I grabbed a magnifying glass and typed the hard to read letters into google. I'm sure that you can guess where this is going...

I'm relieved, but at the same time upset. This is a pretty significant mistake for a supplier to make. The antistatic bag that they had come in was even well labelled as the chip that should have been inside.

Big thanks to everyone who replied to my post. It makes me happy to see how willing to help people are.

Brick

Brick wrote:

You hint that the supplier sent the wrong part. And that you didn't check before plugging the device into a programmer. Ouch, 2x.

PIC & magnifying glass. Been there many times myself! Microchip's laser-etch needs vitamins ... or something. Even brand new Microchips are near impossible for my eyes to read, and impossible to read if when light strikes at the wrong angle. Gimme those bold, white markings! Some of my earliest PICs have been handled countless times and their markings are long-gone; I've stuck a sliver of diskette label on those and written part# on that.

Glad you squashed your problem.