Searching \ for 'Verifying software rev in production' 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/index.htm?key=verifying+software
Search entire site for: 'Verifying software rev in production'.

Truncated match.
PICList Thread
'Verifying software rev in production'
2000\04\05@180554 by Mike Mansheim

flavicon
face
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii

I've seen brief "near references" to this topic lately, but haven't seen my
question directly addressed.
We have in production a design that takes advantage of ICSP by programming
the pic (C73B) at the final assembly of the product (using a Promate II).
Several models use the same circuit board, but different software versions.
If code protection is used, what is the best way for our assembly line to
verify the software version that a given board was programmed with?  We
would like the ability to check AFTER programming in addition to the usual
check at the time of programming.
It would seem to me that if you cannot read a code protected part, then you
can't do a checksum on it either.  Anyone have the scoop on this?
Thanks.

2000\04\05@183759 by Jerry Merrill

flavicon
face
1. You could use the ID locations - they are accessible by your ICSP after
code-protecting.

2. If you have a spare pin, you could have the firmware bit-bang its
version code out immediately after each reset.

3. If your application normally uses a serial interface, you could extend
its protocol so that you could just ASK it for its ID.

4. If you use port pins to select and write data to external devices, you
could:
 a) define a hole in your memory map.  Then write your ID to that
'un-decoded' space on power up.  Use a test fixture to decode the hole and
capture the data.
 b) or WRITE your ID to a space that is normally READ ONLY - benign to the
target but unique to your in-house test fixture.



At 05:02 PM 4/5/00 , you wrote:
{Quote hidden}

Jerry Merrill

spam_OUTjerrymTakeThisOuTspamtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

2000\04\05@184004 by Tony Nixon

flavicon
picon face
Mike Mansheim wrote:
>
> MIME-Version: 1.0
> Content-type: text/plain; charset=us-ascii
>
> I've seen brief "near references" to this topic lately, but haven't seen my
> question directly addressed.
> We have in production a design that takes advantage of ICSP by programming
> the pic (C73B) at the final assembly of the product (using a Promate II).
> Several models use the same circuit board, but different software versions.
> If code protection is used, what is the best way for our assembly line to
> verify the software version that a given board was programmed with?  We
> would like the ability to check AFTER programming in addition to the usual
> check at the time of programming.
> It would seem to me that if you cannot read a code protected part, then you
> can't do a checksum on it either.  Anyone have the scoop on this?
> Thanks.

The ID locations can be read.

Use a different ID for different versions.


--
Best regards

Tony

http://www.picnpoke.com
.....salesKILLspamspam@spam@picnpoke.com

2000\04\06@110057 by Dan Michaels

flavicon
face
Mike Mansheim wrote:
>
>I've seen brief "near references" to this topic lately, but haven't seen my
>question directly addressed.
>We have in production a design that takes advantage of ICSP by programming
>the pic (C73B) at the final assembly of the product (using a Promate II).
>Several models use the same circuit board, but different software versions.
>If code protection is used, what is the best way for our assembly line to
>verify the software version that a given board was programmed with?  We
>would like the ability to check AFTER programming in addition to the usual
>check at the time of programming.
>It would seem to me that if you cannot read a code protected part, then you
>can't do a checksum on it either.  Anyone have the scoop on this?
>Thanks.
>

Related to this, is it not possible to program a PIC without
setting the code protection, then verify the chip, and then
set the code protection afterwards? Or will the CP bits not
comply here?

2000\04\06@110714 by Andrew Kunz

flavicon
face
That works fine.  I have customers who use this technique for their production.

You have to have a burner which allows you to overwrite, rather than forcing a
start with a blank chip.

Andy










Dan Michaels <oricomspamKILLspamLYNX.SNI.NET> on 04/06/2000 10:58:01 AM

Please respond to pic microcontroller discussion list <.....PICLISTKILLspamspam.....MITVMA.MIT.EDU>








To:      EraseMEPICLISTspam_OUTspamTakeThisOuTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Verifying software rev in production








Mike Mansheim wrote:
{Quote hidden}

Related to this, is it not possible to program a PIC without
setting the code protection, then verify the chip, and then
set the code protection afterwards? Or will the CP bits not
comply here?

2000\04\08@033130 by David E Arnold

picon face
How 'bout writing a small function or small piece of code that you can trigger
from the i/o pins in some manner or a small bit of startup code that
outputs Rev info on an unused  serial i/o pin at reset, or even a used one if
it's
isolated properly. This code could perform a checksum on it's self, and compare
to the known checksum which can be internally stored, or simply output that
checksum on the i/o pin. Maybe simply storing Rev info internally and outputting
that is enough.  Kinda like a version string output for software.

-Dave







Andrew Kunz <akunzspamspam_OUTTDIPOWER.COM> on 04/06/2000 08:05:05 AM

Please respond to pic microcontroller discussion list <@spam@PICLISTKILLspamspamMITVMA.MIT.EDU>

To:   KILLspamPICLISTKILLspamspamMITVMA.MIT.EDU
cc:    (bcc: David E Arnold/SYBASE)
Subject:  Re: Verifying software rev in production




That works fine.  I have customers who use this technique for their production.

You have to have a burner which allows you to overwrite, rather than forcing a
start with a blank chip.

Andy










Dan Michaels <RemoveMEoricomTakeThisOuTspamLYNX.SNI.NET> on 04/06/2000 10:58:01 AM

Please respond to pic microcontroller discussion list <spamBeGonePICLISTspamBeGonespamMITVMA.MIT.EDU>








To:      TakeThisOuTPICLISTEraseMEspamspam_OUTMITVMA.MIT.EDU

cc:      (bcc: Andrew Kunz/TDI_NOTES)



Subject: Re: Verifying software rev in production








Mike Mansheim wrote:
{Quote hidden}

Related to this, is it not possible to program a PIC without
setting the code protection, then verify the chip, and then
set the code protection afterwards? Or will the CP bits not
comply here?

2000\04\08@042428 by David E Arnold

picon face
Hi Jerry,

Sounds like you know what youre doing. Well, I'm wondering
what is a test fixture? If never done mass production on anyhting.

Is this an assembly line type of tool?

The hole in memory map technique, can this be done with serial
memory interfaces? I only have experience with parallel address
bus decoding.

-Dave





Jerry Merrill <RemoveMEjerrymspamTakeThisOuTTECH-TOOLS.COM> on 04/05/2000 03:35:09 PM

Please respond to pic microcontroller discussion list <PICLISTEraseMEspam.....MITVMA.MIT.EDU>

To:   EraseMEPICLISTspamMITVMA.MIT.EDU
cc:    (bcc: David E Arnold/SYBASE)
Subject:  Re: Verifying software rev in production




1. You could use the ID locations - they are accessible by your ICSP after
code-protecting.

2. If you have a spare pin, you could have the firmware bit-bang its
version code out immediately after each reset.

3. If your application normally uses a serial interface, you could extend
its protocol so that you could just ASK it for its ID.

4. If you use port pins to select and write data to external devices, you
could:
 a) define a hole in your memory map.  Then write your ID to that
'un-decoded' space on power up.  Use a test fixture to decode the hole and
capture the data.
 b) or WRITE your ID to a space that is normally READ ONLY - benign to the
target but unique to your in-house test fixture.



At 05:02 PM 4/5/00 , you wrote:
{Quote hidden}

Jerry Merrill

RemoveMEjerrymEraseMEspamEraseMEtech-tools.com
http://www.tech-tools.com
FAX: (972) 494-5814
VOICE:(972) 272-9392
TechTools
PO Box 462101
Garland,  TX  75046-2101

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