Trouble With my PIC Programmer

[Brick]

Hello,

I just purchased a baseline flash microcontroller programmer for
programming 10f series pics. Unfortunately I'm having a difficult time
getting it to work.

The software recognizes the programmer fine and everything seems to
work, but when I try to read a chip every memory address reads as 0. If
I write to a chip it will seem to work and then fail on the verify
(which just means that it is reading all 0's again). At first I thought
that maybe I had fried the chip so I tried using a different one and
was very, very careful about static discharge. Same thing. Then I
thought that maybe I made a mistake when I made the pdip adapter, but
I've checked it over several times with the datasheet. I even checked
to make sure that all of the connections were well connected to the
chip's pins.

I'm lost about what to do now. I can't find any relevant documentation
on the programmer and I'm out of ideas. If anyone has anything that
might steer me in the right direction I would be very thankful.

Brick

 

[petrus bitbyter]

Hello,

I just purchased a baseline flash microcontroller programmer for
programming 10f series pics. Unfortunately I'm having a difficult time
getting it to work.

The software recognizes the programmer fine and everything seems to
work, but when I try to read a chip every memory address reads as 0. If
I write to a chip it will seem to work and then fail on the verify
(which just means that it is reading all 0's again). At first I thought
that maybe I had fried the chip so I tried using a different one and
was very, very careful about static discharge. Same thing. Then I
thought that maybe I made a mistake when I made the pdip adapter, but
I've checked it over several times with the datasheet. I even checked
to make sure that all of the connections were well connected to the
chip's pins.

I'm lost about what to do now. I can't find any relevant documentation
on the programmer and I'm out of ideas. If anyone has anything that
might steer me in the right direction I would be very thankful.

Brick

Brick,

Do you have the available doc? See:
http://www.microchip.com/stellent/i...E&nodeId=1406&dDocName=en020756&part=PG164101
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

 

[Brick]

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.

 

[Luhan]

Hello,

I just purchased a baseline flash microcontroller programmer for

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

 

[Brick]

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

 

[Brick]

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.

 

[Brick]

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.

 

[Jamie]

Hello,

I just purchased a baseline flash microcontroller programmer for
programming 10f series pics. Unfortunately I'm having a difficult time
getting it to work.

The software recognizes the programmer fine and everything seems to
work, but when I try to read a chip every memory address reads as 0. If
I write to a chip it will seem to work and then fail on the verify
(which just means that it is reading all 0's again). At first I thought
that maybe I had fried the chip so I tried using a different one and
was very, very careful about static discharge. Same thing. Then I
thought that maybe I made a mistake when I made the pdip adapter, but
I've checked it over several times with the datasheet. I even checked
to make sure that all of the connections were well connected to the
chip's pins.

I'm lost about what to do now. I can't find any relevant documentation
on the programmer and I'm out of ideas. If anyone has anything that
might steer me in the right direction I would be very thankful.

Brick

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.

 

[Jamie]

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.

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 ?

 

[petrus bitbyter]

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.

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

 

[Michael]

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

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!

 

[Brick]

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

 

[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

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.