Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #24524 > unrolled thread

dsPIC serial number

Back to article view | Back to comp.arch.embedded

Contents

  dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-03 11:51 +0100
    Re: dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-03 12:01 +0100
    Re: dsPIC serial number Don Y <blockedofcourse@foo.invalid> - 2016-07-03 04:14 -0700
      Re: dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-03 12:46 +0100
        Re: dsPIC serial number Don Y <blockedofcourse@foo.invalid> - 2016-07-03 05:24 -0700
          Re: dsPIC serial number Don Y <blockedofcourse@foo.invalid> - 2016-07-03 05:28 -0700
            Re: dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-03 16:13 +0100
              Re: dsPIC serial number Don Y <blockedofcourse@foo.invalid> - 2016-07-05 17:35 -0700
                Re: dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-06 11:06 +0100
                  Re: dsPIC serial number Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-06 13:44 +0300
                    Re: dsPIC serial number Syd Rumpo <usenet@nononono.co.uk> - 2016-07-06 13:16 +0100
                      Re: dsPIC serial number Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-06 16:36 +0300
                  Re: dsPIC serial number Richard Damon <Richard@Damon-Family.org> - 2016-07-16 21:50 -0400
    Re: dsPIC serial number Paul Rubin <no.email@nospam.invalid> - 2016-07-03 09:46 -0700
    Re: dsPIC serial number Les Cargill <lcargill99@comcast.com> - 2016-07-03 12:46 -0500
      Re: dsPIC serial number Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2016-07-03 21:04 +0300

#24524 — dsPIC serial number

Hi

I want to put a serial number into a dsPIC - there's four bytes of user 
space in the flash which would be ideal.

Is there any reasonably easy way of stopping this from being changed 
when new software is programmed using a PicKit programmer?  I know I 
could read it and re-write it, but I want something which moderately 
tech-savvy customers can do.

Cheers
-- 
Syd

[toc] | [next] | [standalone]

#24525

On 03/07/2016 11:51, Syd Rumpo wrote:
> Hi
>
> I want to put a serial number into a dsPIC - there's four bytes of user
> space in the flash which would be ideal.
>
> Is there any reasonably easy way of stopping this from being changed
> when new software is programmed using a PicKit programmer?  I know I
> could read it and re-write it, but I want something which moderately
> tech-savvy customers can do.
>

I should add that this would be less than one hundred units, so no 
custom parts.  If it comes to it I'll use a serial number chip, but I'd 
rather not bother.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#24526

On 7/3/2016 3:51 AM, Syd Rumpo wrote:
> I want to put a serial number into a dsPIC - there's four bytes of user space
> in the flash which would be ideal.
>
> Is there any reasonably easy way of stopping this from being changed when new
> software is programmed using a PicKit programmer?  I know I could read it and
> re-write it, but I want something which moderately tech-savvy customers can do.

I'm unclear of your goal.

Do you want to serialize each device in such a way that a "smart"
user can't alter the serial number, intentionally?  (e.g., to gain
access to features)

Or, do you want "smart" users to be able to update the software and
you just want to HELP protect them from *accidentally* overwriting
the serial number?  (i.e., with the bogus S/N that may be present in those
4 bytes in the "updated image")

[toc] | [prev] | [next] | [standalone]

#24527

On 03/07/2016 12:14, Don Y wrote:
> On 7/3/2016 3:51 AM, Syd Rumpo wrote:
>> I want to put a serial number into a dsPIC - there's four bytes of
>> user space
>> in the flash which would be ideal.
>>
>> Is there any reasonably easy way of stopping this from being changed
>> when new
>> software is programmed using a PicKit programmer?  I know I could read
>> it and
>> re-write it, but I want something which moderately tech-savvy
>> customers can do.
>
> I'm unclear of your goal.
>
> Do you want to serialize each device in such a way that a "smart"
> user can't alter the serial number, intentionally?  (e.g., to gain
> access to features)
>
> Or, do you want "smart" users to be able to update the software and
> you just want to HELP protect them from *accidentally* overwriting
> the serial number?  (i.e., with the bogus S/N that may be present in those
> 4 bytes in the "updated image")
>
The second really.  I want to program a number when the boards are made 
and not have it accidentally changed by the user updating the software. 
There's no real reason they'd want to alter it deliberately.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#24528

On 7/3/2016 4:46 AM, Syd Rumpo wrote:
> On 03/07/2016 12:14, Don Y wrote:
>> On 7/3/2016 3:51 AM, Syd Rumpo wrote:
>>> I want to put a serial number into a dsPIC - there's four bytes of
>>> user space
>>> in the flash which would be ideal.
>>>
>>> Is there any reasonably easy way of stopping this from being changed
>>> when new
>>> software is programmed using a PicKit programmer?  I know I could read
>>> it and
>>> re-write it, but I want something which moderately tech-savvy
>>> customers can do.
>>
>> I'm unclear of your goal.
>>
>> Do you want to serialize each device in such a way that a "smart"
>> user can't alter the serial number, intentionally?  (e.g., to gain
>> access to features)
>>
>> Or, do you want "smart" users to be able to update the software and
>> you just want to HELP protect them from *accidentally* overwriting
>> the serial number?  (i.e., with the bogus S/N that may be present in those
>> 4 bytes in the "updated image")
>>
> The second really.  I want to program a number when the boards are made and not
> have it accidentally changed by the user updating the software. There's no real
> reason they'd want to alter it deliberately.

Can you arrange for the "4 extra bytes" to be at the *end* of the image?
Then, set the "End" address to be 4 bytes short of the physical end of
memory?  There's also an option to "preserve" a portion of the memory
range that might be able to be more accommodating.

What you'll have to verify is that the "unpreserved" portion -- and
ONLY the unpreserved portion -- is erased before programming.

And, of course, you'll have to hope your "tech savvy users" can
follow directions EXACTLY.  Are those 4 bytes written (pen and ink)
anywhere that a user could reinitialize them if he shoots himself
in the foot?

[I'm not sure if you also have to elide the "4 bytes" from your "image".]

[toc] | [prev] | [next] | [standalone]

#24529

On 7/3/2016 5:24 AM, Don Y wrote:

>>> Or, do you want "smart" users to be able to update the software and
>>> you just want to HELP protect them from *accidentally* overwriting
>>> the serial number?  (i.e., with the bogus S/N that may be present in those
>>> 4 bytes in the "updated image")
>>>
>> The second really.  I want to program a number when the boards are made and not
>> have it accidentally changed by the user updating the software. There's no real
>> reason they'd want to alter it deliberately.
>
> Can you arrange for the "4 extra bytes" to be at the *end* of the image?
> Then, set the "End" address to be 4 bytes short of the physical end of
> memory?  There's also an option to "preserve" a portion of the memory
> range that might be able to be more accommodating.
>
> What you'll have to verify is that the "unpreserved" portion -- and
> ONLY the unpreserved portion -- is erased before programming.
>
> And, of course, you'll have to hope your "tech savvy users" can
> follow directions EXACTLY.  Are those 4 bytes written (pen and ink)
> anywhere that a user could reinitialize them if he shoots himself
> in the foot?
>
> [I'm not sure if you also have to elide the "4 bytes" from your "image".]

Another option might be viable depending on how you distribute the
images.  Are they downloaded from a generic image on a web site?
Can you write a little tool that manipulates the image to merge in
the S/N *before* making the image available to the programmer?
I.e., deliberately distribute it in a form that is incompatible
with the programmer until it is massaged into the proper form
(with the extra bytes injected).

[Of course, that still allows someone to program several devices
with the same image, same S/N...]

[toc] | [prev] | [next] | [standalone]

#24532

On 03/07/2016 13:28, Don Y wrote:

<snipped>

Some good ideas there, thanks Don.

I think you've convinced me that it can't be done /easily/, so it looks 
like a serial ID chip is needed.  I was rather hoping there was 
something I'd overlooked in the manual.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#24550

On 7/3/2016 8:13 AM, Syd Rumpo wrote:
> I think you've convinced me that it can't be done /easily/, so it looks like a
> serial ID chip is needed.  I was rather hoping there was something I'd
> overlooked in the manual.

I guess it depends on what you consider "easily" -- the fact that
you're expecting (?) folks to do the upgrades themselves suggests
you've already imposed a certain level of competence on them.

Another way of looking at it:  what's the potential (loss of)
value if they "get the number wrong"?  Will the product stop
working?  (you've previously indicated the "correct number" doesn't
entitle them to anything special...)

[toc] | [prev] | [next] | [standalone]

#24553

On 06/07/2016 01:35, Don Y wrote:
> On 7/3/2016 8:13 AM, Syd Rumpo wrote:
>> I think you've convinced me that it can't be done /easily/, so it
>> looks like a
>> serial ID chip is needed.  I was rather hoping there was something I'd
>> overlooked in the manual.
>
> I guess it depends on what you consider "easily" -- the fact that
> you're expecting (?) folks to do the upgrades themselves suggests
> you've already imposed a certain level of competence on them.
>
> Another way of looking at it:  what's the potential (loss of)
> value if they "get the number wrong"?  Will the product stop
> working?  (you've previously indicated the "correct number" doesn't
> entitle them to anything special...)

The customers would usually have access to a PIC programmer - both the 
equipment and the person - of some kind and would get a hex file, 
probably by email or from the web.  I can't mandate a particular type of 
programmer.

I had hoped that there was some easy way of embedding a number in the 
dsPIC and not overwriting it when firmware is changed.  The ID is really 
for traceability.  Sadly, the dsPIC has no EEPROM.

Cheers
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#24555

On 6.7.16 13:06, Syd Rumpo wrote:
> On 06/07/2016 01:35, Don Y wrote:
>> On 7/3/2016 8:13 AM, Syd Rumpo wrote:
>>> I think you've convinced me that it can't be done /easily/, so it
>>> looks like a
>>> serial ID chip is needed.  I was rather hoping there was something I'd
>>> overlooked in the manual.
>>
>> I guess it depends on what you consider "easily" -- the fact that
>> you're expecting (?) folks to do the upgrades themselves suggests
>> you've already imposed a certain level of competence on them.
>>
>> Another way of looking at it:  what's the potential (loss of)
>> value if they "get the number wrong"?  Will the product stop
>> working?  (you've previously indicated the "correct number" doesn't
>> entitle them to anything special...)
>
> The customers would usually have access to a PIC programmer - both the
> equipment and the person - of some kind and would get a hex file,
> probably by email or from the web.  I can't mandate a particular type of
> programmer.
>
> I had hoped that there was some easy way of embedding a number in the
> dsPIC and not overwriting it when firmware is changed.  The ID is really
> for traceability.  Sadly, the dsPIC has no EEPROM.
>
> Cheers

The configuration registers are separate from the code memory.
There are some user bytes in the register bank. A normal program
update should not write anything to the configuration area.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#24556

On 06/07/2016 11:44, Tauno Voipio wrote:
> On 6.7.16 13:06, Syd Rumpo wrote:
>> On 06/07/2016 01:35, Don Y wrote:
>>> On 7/3/2016 8:13 AM, Syd Rumpo wrote:
>>>> I think you've convinced me that it can't be done /easily/, so it
>>>> looks like a
>>>> serial ID chip is needed.  I was rather hoping there was something I'd
>>>> overlooked in the manual.
>>>
>>> I guess it depends on what you consider "easily" -- the fact that
>>> you're expecting (?) folks to do the upgrades themselves suggests
>>> you've already imposed a certain level of competence on them.
>>>
>>> Another way of looking at it:  what's the potential (loss of)
>>> value if they "get the number wrong"?  Will the product stop
>>> working?  (you've previously indicated the "correct number" doesn't
>>> entitle them to anything special...)
>>
>> The customers would usually have access to a PIC programmer - both the
>> equipment and the person - of some kind and would get a hex file,
>> probably by email or from the web.  I can't mandate a particular type of
>> programmer.
>>
>> I had hoped that there was some easy way of embedding a number in the
>> dsPIC and not overwriting it when firmware is changed.  The ID is really
>> for traceability.  Sadly, the dsPIC has no EEPROM.
>>
>> Cheers
>
> The configuration registers are separate from the code memory.
> There are some user bytes in the register bank. A normal program
> update should not write anything to the configuration area.
>

I had assumed that as the configuration registers are set from the 
source code the user bytes would be overwritten or cleared.

As it happens, if I set them from source code using...

_FUID0(0xDE);
_FUID1(0xAD);
_FUID2(0xBE);
_FUID3(0xEF);

... and program the chip, then remove these lines and reprogram, they 
don't get overwritten and DEADBEEF remains!

I only just tried that to prove that Tauno was wrong.  He wasn't.

Thanks!
-- 
Syd

[toc] | [prev] | [next] | [standalone]

#24557

On 6.7.16 15:16, Syd Rumpo wrote:
> On 06/07/2016 11:44, Tauno Voipio wrote:
>> On 6.7.16 13:06, Syd Rumpo wrote:
>>> On 06/07/2016 01:35, Don Y wrote:
>>>> On 7/3/2016 8:13 AM, Syd Rumpo wrote:
>>>>> I think you've convinced me that it can't be done /easily/, so it
>>>>> looks like a
>>>>> serial ID chip is needed.  I was rather hoping there was something I'd
>>>>> overlooked in the manual.
>>>>
>>>> I guess it depends on what you consider "easily" -- the fact that
>>>> you're expecting (?) folks to do the upgrades themselves suggests
>>>> you've already imposed a certain level of competence on them.
>>>>
>>>> Another way of looking at it:  what's the potential (loss of)
>>>> value if they "get the number wrong"?  Will the product stop
>>>> working?  (you've previously indicated the "correct number" doesn't
>>>> entitle them to anything special...)
>>>
>>> The customers would usually have access to a PIC programmer - both the
>>> equipment and the person - of some kind and would get a hex file,
>>> probably by email or from the web.  I can't mandate a particular type of
>>> programmer.
>>>
>>> I had hoped that there was some easy way of embedding a number in the
>>> dsPIC and not overwriting it when firmware is changed.  The ID is really
>>> for traceability.  Sadly, the dsPIC has no EEPROM.
>>>
>>> Cheers
>>
>> The configuration registers are separate from the code memory.
>> There are some user bytes in the register bank. A normal program
>> update should not write anything to the configuration area.
>>
>
> I had assumed that as the configuration registers are set from the
> source code the user bytes would be overwritten or cleared.
>
> As it happens, if I set them from source code using...
>
> _FUID0(0xDE);
> _FUID1(0xAD);
> _FUID2(0xBE);
> _FUID3(0xEF);
>
> ... and program the chip, then remove these lines and reprogram, they
> don't get overwritten and DEADBEEF remains!
>
> I only just tried that to prove that Tauno was wrong.  He wasn't.
>
> Thanks!

I made a dsPIC loader, see
<http://www.sdr-cube.com/Bootloader/index.html>.

-- 

-TV

[toc] | [prev] | [next] | [standalone]

#24628

On 7/6/16 6:06 AM, Syd Rumpo wrote:
> On 06/07/2016 01:35, Don Y wrote:
>> On 7/3/2016 8:13 AM, Syd Rumpo wrote:
>>> I think you've convinced me that it can't be done /easily/, so it
>>> looks like a
>>> serial ID chip is needed.  I was rather hoping there was something I'd
>>> overlooked in the manual.
>>
>> I guess it depends on what you consider "easily" -- the fact that
>> you're expecting (?) folks to do the upgrades themselves suggests
>> you've already imposed a certain level of competence on them.
>>
>> Another way of looking at it:  what's the potential (loss of)
>> value if they "get the number wrong"?  Will the product stop
>> working?  (you've previously indicated the "correct number" doesn't
>> entitle them to anything special...)
>
> The customers would usually have access to a PIC programmer - both the
> equipment and the person - of some kind and would get a hex file,
> probably by email or from the web.  I can't mandate a particular type of
> programmer.
>
> I had hoped that there was some easy way of embedding a number in the
> dsPIC and not overwriting it when firmware is changed.  The ID is really
> for traceability.  Sadly, the dsPIC has no EEPROM.
>
> Cheers

I thought the programmer only erased flash pages that had data in them 
from the programming file (unless you manually commanded a total erase) 
so if you put the serial number in a page that didn't have any data from 
the program, it wouldn't get lost in a normal reprogram cycle.

[toc] | [prev] | [next] | [standalone]

#24533

Syd Rumpo <usenet@nononono.co.uk> writes:
> I want to put a serial number into a dsPIC - there's four bytes of
> user space in the flash which would be ideal.

Do some of those parts have some eeprom?  That's intended for that sort
of purpose.

[toc] | [prev] | [next] | [standalone]

#24536

Syd Rumpo wrote:
> Hi
>
> I want to put a serial number into a dsPIC - there's four bytes of user
> space in the flash which would be ideal.
>
> Is there any reasonably easy way of stopping this from being changed
> when new software is programmed using a PicKit programmer?  I know I
> could read it and re-write it, but I want something which moderately
> tech-savvy customers can do.
>
> Cheers


This has a table which shows the erase and write blocks for a dsPIC.

http://ww1.microchip.com/downloads/en/DeviceDoc/70152H.pdf

I dunno whether a PicKit can pick ( hah! ) and choose which blocks it 
reprograms or not. The single examples using an ICD3 I've seen used did 
not but that was on a PIC24 and on a PIC32. Serial numbers were managed 
with a barcode on the case, and there were Noi User Serviceable Parts 
Inside - upgrades were done only in an RMR facility.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#24537

On 3.7.16 20:46, Les Cargill wrote:
> Syd Rumpo wrote:
>> Hi
>>
>> I want to put a serial number into a dsPIC - there's four bytes of user
>> space in the flash which would be ideal.
>>
>> Is there any reasonably easy way of stopping this from being changed
>> when new software is programmed using a PicKit programmer?  I know I
>> could read it and re-write it, but I want something which moderately
>> tech-savvy customers can do.
>>
>> Cheers
>
>
> This has a table which shows the erase and write blocks for a dsPIC.
>
> http://ww1.microchip.com/downloads/en/DeviceDoc/70152H.pdf
>
> I dunno whether a PicKit can pick ( hah! ) and choose which blocks it
> reprograms or not. The single examples using an ICD3 I've seen used did
> not but that was on a PIC24 and on a PIC32. Serial numbers were managed
> with a barcode on the case, and there were Noi User Serviceable Parts
> Inside - upgrades were done only in an RMR facility.


Check the configuration bytes at 0xf8010 - 0xf8017. They are reserved
as User Unit ID Bytes.

-- 

-TV

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch.embedded

csiph-web