dsPIC serial number

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