Searching \ for '[PIC]: verifying from vddmin to vddmax & bootloadi' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/power/decouple.htm?key=vdd
Search entire site for: 'verifying from vddmin to vddmax & bootloadi'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: verifying from vddmin to vddmax & bootloadi'
2001\01\31@051307 by Simon Nield

flavicon
face
the recent thread on 16f877 programming inspired a little musing:

'decent' programming hardware apparently verifies a part over a range of Vdd values to ensure the
bits have been set correctly.

it would seem that using a bootloader with a flash part the bits are only be verified at the current
vdd.

possible conclusions:

(1) a bootloaded part may be less reliable than a 'hardware programmed' part.

(2) there's no need to do the whole vdd range thing with flash - it's a technique that's only
meaningful for eprom type memory cells.

(3) there's some cunning circuitry inside the flash parts that does actually ram the voltage supply
down (and up ?) to the extents of legal vdd during the verify.



any of you have anything _other_ than anecdotal evidence to support any of these possible
conclusions, or indeed some other conclusion i have missed ?

it's a semiconductor design question really, something i have no experience of... i'm not really
interested in the problem from the aspect of designing a programmer that meets the spec.

Regards,
Simon

--
http://www.piclist.com hint: To leave the PICList
spam_OUTpiclist-unsubscribe-requestTakeThisOuTspammitvma.mit.edu


2001\01\31@080335 by Bob Ammerman

picon face
----- Original Message -----
From: Simon Nield <.....simon.nieldKILLspamspam@spam@QUANTEL.COM>
To: <PICLISTspamKILLspamMITVMA.MIT.EDU>
Sent: Wednesday, January 31, 2001 5:12 AM
Subject: [PIC]: verifying from vddmin to vddmax & bootloading


> the recent thread on 16f877 programming inspired a little musing:
>
> 'decent' programming hardware apparently verifies a part over a range of
Vdd values to ensure the
> bits have been set correctly.
>
> it would seem that using a bootloader with a flash part the bits are only
be verified at the current
> vdd.

> possible conclusions:
>
> (1) a bootloaded part may be less reliable than a 'hardware programmed'
part.

Just maybe

> (2) there's no need to do the whole vdd range thing with flash - it's a
technique that's only
> meaningful for eprom type memory cells.

Not according to Mchips data sheet

> (3) there's some cunning circuitry inside the flash parts that does
actually ram the voltage supply
> down (and up ?) to the extents of legal vdd during the verify.

Not very likely

>
>
> any of you have anything _other_ than anecdotal evidence to support any of
these possible
> conclusions, or indeed some other conclusion i have missed ?
>

How about:

(4) Maybe flash doesn't care about margining Vdd (tho' I don't see why not),
but now Mchip can sell a lot more expensive 'production' programmers.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam.....mitvma.mit.edu


2001\01\31@083100 by mike

flavicon
face
On Wed, 31 Jan 2001 10:12:09 +0000, you wrote:

>the recent thread on 16f877 programming inspired a little musing:
>
>'decent' programming hardware apparently verifies a part over a range of Vdd values to ensure the
>bits have been set correctly.
I believe this is only the case for OTP parts
>
>it would seem that using a bootloader with a flash part the bits are only be verified at the current
>vdd.
>possible conclusions:
>
>(1) a bootloaded part may be less reliable than a 'hardware programmed' part.
>
>(2) there's no need to do the whole vdd range thing with flash - it's a technique that's only
>meaningful for eprom type memory cells.
This would be a reasonable assumption. The flash write self-timing
will probably ensure sufficient overprogramming to cover all voltage
ranges.
>(3) there's some cunning circuitry inside the flash parts that does actually ram the voltage supply
>down (and up ?) to the extents of legal vdd during the verify.
Nope - this would cost money to add (die area)

>any of you have anything _other_ than anecdotal evidence to support any of these possible
>conclusions, or indeed some other conclusion i have missed ?
When programmed via bootloader, it's likely that this will be at the
normal application Vdd. A 'socket' programmer doesn't know what
voltage  the chip will run at, and it's therefore more important to
verify the whole range.

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\01\31@110441 by Morgan Olsson

picon face
Simon Nield wrote:
>possible conclusions:
>
>(1) a bootloaded part may be less reliable than a 'hardware programmed' part.

Yes :/

The design and function of an Flash cell is very similar, if not to say exactly the same, IIRC, it is just that the memory is equipped with fast erase (and maybe faster write)

I plan to in future make the PIC control it´s own voltage +-1 Volt or so to verify more securely (and also use that when checking both ProgramFLASH and DataEEPROM checksum at startups)

/Morgan

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestspamspam_OUTmitvma.mit.edu


2001\01\31@112332 by Bob Blick

face
flavicon
face
Only problem I've ever had with PICs at voltage extremes has been from
windowed PICs not being completely erased before reprogramming.

Never a problem with OTP parts or Flash parts.

-Bob

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


More... (looser matching)
- Last day of these posts
- In 2001 , 2002 only
- Today
- New search...