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.

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

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

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

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

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

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

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