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

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

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")

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

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".]

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...]

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

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.

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

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