We have recently migrated from PIC16C622A to PIC16F628. Yesterday we programmed 500 parts (F628) using a Picstart Plus with FW 2.30 / MPLAB 5.30, with the same setup we normally program C622 with (changed device in MPLAB ofcourse). All parts are codeprotected during programming.
Today we started testing the PC boards that came from production, but we're experiencing device failures, on about every 10th device. I tried reprogramming the devices which failed during test, and most works perfectly after a reprogram...
I then tried my development setup, with another Picstart Plus, programmed 25 devices without codeprotection, which where all programmed "successfully" according to Picstart Plus... then I did a "verify" on each device, and 4 out of the 25 failed! Seemed they just read out random data.
Anyone experienced the same?
Another thing; 16F628 is very slow to program in the Picstart Plus compared to 16C622A, probably because of the flashmemory instead of EPROM.. Will Promate be able to program them faster?
>We have recently migrated from PIC16C622A to PIC16F628. Yesterday we
programmed 500 parts (F628) using a Picstart Plus with FW 2.30 / MPLAB 5.30,
with the same setup we normally program C622 with (changed device in MPLAB
ofcourse). All parts are codeprotected during programming.
>
>Today we started testing the PC boards that came from production, but we're
experiencing device failures, on about every 10th device. I tried
reprogramming the devices which failed during test, and most works perfectly
after a reprogram...
.......
Jacob, better contact Microchip immediately. Just yell "500 parts",
and they should give you their undivided attention. It is their
parts and their tools.
We have recently migrated from PIC16C622A to PIC16F628. Yesterday we programmed 500 parts (F628) using a Picstart Plus with FW 2.30 / MPLAB 5.30, with the same setup we normally program C622 with (changed device in MPLAB ofcourse). All parts are codeprotected during programming.
Today we started testing the PC boards that came from production, but we're experiencing device failures, on about every 10th device. I tried reprogramming the devices which failed during test, and most works perfectly after a reprogram...
I then tried my development setup, with another Picstart Plus, programmed 25 devices without codeprotection, which where all programmed "successfully" according to Picstart Plus... then I did a "verify" on each device, and 4 out of the 25 failed! Seemed they just read out random data.
Anyone experienced the same behavior?
Another thing; 16F628 is very slow to program in the Picstart Plus compared to 16C622A, probably because of the flashmemory instead of EPROM.. Will Promate be able to program them faster? And is it possible to program more than one device at a time?
>Jacob, better contact Microchip immediately. Just yell "500 parts",
>and they should give you their undivided attention. It is their
>parts and their tools.
Pictstart+ is "Not a production programmer" so don't get too snooty,
but 10% bad is inexcusable. Did you do the Vpp fix if it was updated
from an earlier version?
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" speffspam_OUTinterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany wrote:
>At 12:46 PM 8/3/01 -0400, you wrote:
>
>>Jacob, better contact Microchip immediately. Just yell "500 parts",
>>and they should give you their undivided attention. It is their
>>parts and their tools.
>
>Pictstart+ is "Not a production programmer" so don't get too snooty,
>but 10% bad is inexcusable. Did you do the Vpp fix if it was updated
>from an earlier version?
>
Shoot, I'd get pretty snooty with 500 parts and all in-family tools.
[however, I think employment of "panic" might be more effective].
Besides, even if not production, it's likely they have been both
programmed and are being used at the same Vcc and temperature.
[?????? you better support me on this Jacob ;-)].
Dan Michaels wrote:
>
>Besides, even if not production, it's likely they have been both
>programmed and are being used at the same Vcc and temperature.
Is verification at different Vcc levels the only distinction between a
production programmer and a development programmer?
Regards, Bob
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> Spehro Pefhany wrote:
> >At 12:46 PM 8/3/01 -0400, you wrote:
> >
> >>Jacob, better contact Microchip immediately. Just yell "500 parts",
> >>and they should give you their undivided attention. It is their
> >>parts and their tools.
It's not just 500 parts.. we only just programmed 500 so far. We have 6000 devices to be ship in the next couple of month.
> >Pictstart+ is "Not a production programmer" so don't get too snooty,
> >but 10% bad is inexcusable. Did you do the Vpp fix if it was updated
> >from an earlier version?
Now this sounds interesting. What is the "Vpp fix"? One programmer was upgraded from FW1.5, the other from 2.0.
> Shoot, I'd get pretty snooty with 500 parts and all in-family tools.
> [however, I think employment of "panic" might be more effective].
I'm actually a bit worried.. Sending out products where some devices may have random biterrors is not really "a good thing" :)
> Besides, even if not production, it's likely they have been both
> programmed and are being used at the same Vcc and temperature.
> [?????? you better support me on this Jacob ;-)].
Yep, that's true. Temperature is the same, and the PIC is powered from a 78L05.
I contacted our local distributor today, which called a Microchip office, but I got exactly the answer I expected... "Picstart + is not recommended for production, use Promate instead".. I then pointed out that having a development programmer that caused malfunction in my firmware isn't really optimal...
>Now this sounds interesting. What is the "Vpp fix"? One programmer was
upgraded from FW1.5, the other from 2.0.
MPLAB Help->Picstart Help->Picstart+ Vpp adjustment (near the bottom)
Required for Rev. 7 or lower.
The 1.5 certainly sounds suspicious, not sure about the other one.
Interesting that you are using two
programmers, I wonder if there is any correlation.
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" speffEraseME.....interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> At 09:48 PM 8/3/01 +0200, you wrote:
>
> >Now this sounds interesting. What is the "Vpp fix"? One programmer was
> upgraded from FW1.5, the other from 2.0.
>
> MPLAB Help->Picstart Help->Picstart+ Vpp adjustment (near the bottom)
> Required for Rev. 7 or lower.
Can the revision number be identified on the back? Assy#? In that case, the FW1.5 programmer is R11, and the FW2.0 is R13..
> The 1.5 certainly sounds suspicious, not sure about the other one.
> Interesting that you are using two
> programmers, I wonder if there is any correlation.
I have problems using both programmers, on 2 different PCs.
Jacob.B wrote:
.........
>
>> Besides, even if not production, it's likely they have been both
>> programmed and are being used at the same Vcc and temperature.
>> [?????? you better support me on this Jacob ;-)].
>
>Yep, that's true. Temperature is the same, and the PIC is powered from a 78L05.
>
>I contacted our local distributor today, which called a Microchip office,
but I got exactly the answer I expected... "Picstart + is not recommended
for production, use Promate instead".. I then pointed out that having a
development programmer that caused malfunction in my firmware isn't really
optimal...
>
Well, this was exactly my point. It sounded like you simply
programmed them, and tested them in-house - not even in the field
with varying Vcc and temperature conditions - and some failed
already. I should think a "properly-designed" development
programmer should pass this test - WITHOUT a load of bullshit
coming back from the manufacturer. For crying out loud already
....... [US slang].
OTOH, older programmers/firmware may not set all the programming
parameters optimally for the newer chips. I believe melabs had to
do some fiddling with their EPIC s.w. because of this - lengthened
the delays, IIRC.
Also, you might check that your Vpp voltage is correct.
Regarding differences between production and protoyping, besides
using hi/lo Vcc tests .......
my EPIC is a prototyper, but they actually program the chip on
one pass, testing the ROM cells for proper values as they go,
then go back and set the code protect bits at the end. Some
prototyper programmers may not do this, so you may not know
whether you got the correct data into the cells when doing
code protect.
Jacob Blichfeldt wrote:
>
> > Spehro Pefhany wrote:
> > >At 12:46 PM 8/3/01 -0400, you wrote:
> > >
> > >>Jacob, better contact Microchip immediately. Just yell "500 parts",
> > >>and they should give you their undivided attention. It is their
> > >>parts and their tools.
>
> It's not just 500 parts.. we only just programmed 500 so far. We have 6000 devices to be ship in the next couple of month.
Jacob, try programming a test batch twice...
Also check the temperature when the chip is
programmed and used, with flash this can be as
temperature sensitive as voltage sensitive, and
even the production programmers don't test
temperature options. Maybe try programming
a batch in a hotter or colder environment, and
examine your current temperature differential
between where you are programming them and where
you are using them.
:o)
-Roman
>I have problems using both programmers, on 2 different PCs.
Was the person doing the programming the same one? And not
you?
A long shot, perhaps, but I've seen problems with sloppy
operation and ignoring the feedback from the programmer.
A couple of rails of ruined OTP parts...
Best regards,
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Spehro Pefhany --"it's the network..." "The Journey is the reward" RemoveMEspeffKILLspaminterlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Contributions invited->The AVR-gcc FAQ is at: http://www.bluecollarlinux.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
The PICStart Plus is a development programmer. It is not intended to be used
from production. It does not varying the supply voltage during progamming.
It is required to insure that the part's programming will be valid for the
entire range of input supply values. Use a production programmer (like those
offered by Advanced Transdata).
blichfeldt.dk
