standalone programmer for PIC?

Byron

That means the service engineer onsite owns a copy of hex code which
we do not really want.  Also, the device is installed in odd area that
bring a laptop and climb up long ladder is not a very nice way to do.

Battery driven uploader is the ultimate goal.

Rgds

Calvin
On 16 Dec 2004 12:26:58 -0500, byron@cc.gatech.edu (Byron A Jeff)
wrote:

>In article <jcs1s052kikpahm8oo0tird5kqurhvklm9@4ax.com>,
>Calvin Chan  <calvin_chan@post1.com> wrote:
>-Hi Folks
>-
>-I have been looking into some sorts of portable standalone programmers
>-for PIC.  The idea is for on site firmware update.
>-
>-The idea is to preload the programmer with the firmware hex code
>-(presumably the programmer is equipped with flash/eeprom to house the
>-binary code.  For security reason, the hex code is not distributed),
>-and the service engineer will take the programmer to site, and plug
>-into the device to reprogram via ISP.
>-
>-Does anyone come across this type of device, or can anyone points me
>-to relevant links?  Thanks
>
>If you have the right part, you can simply implement a bootloader with
>a secure protocol. It just requires a PIC that can program itself. These
>include the 16F88 in the 18 pin package, the 16F876A and 16F877A in the
>28 and 40 pin package, or any of the 18F parts.
>
>Then you wouldn't need a standalone programmer at all. Just plug a serial
>port into the chip, and run the right piece of software, and you're done.
>
>BAJ

On Fri, 17 Dec 2004 10:26:40 +0800, the renowned Calvin Chan
<calvin_chan@post1.com> wrote:

>Byron
>
>That means the service engineer onsite owns a copy of hex code which
>we do not really want.  Also, the device is installed in odd area that
>bring a laptop and climb up long ladder is not a very nice way to do.
>
>Battery driven uploader is the ultimate goal.
>
>Rgds

He means that the file is encrypted and the bootloader program inside
the PIC decrypts it before writing it to flash. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

Thanks for the clarification, but that cannot solve the odd position
of installation of device which warrants to handheld programmer.

Calvin

On Thu, 16 Dec 2004 21:43:46 -0500, Spehro Pefhany
<speffSNIP@interlogDOTyou.knowwhat> wrote:

>On Fri, 17 Dec 2004 10:26:40 +0800, the renowned Calvin Chan
><calvin_chan@post1.com> wrote:
>
>>Byron
>>
>>That means the service engineer onsite owns a copy of hex code which
>>we do not really want.  Also, the device is installed in odd area that
>>bring a laptop and climb up long ladder is not a very nice way to do.
>>
>>Battery driven uploader is the ultimate goal.
>>
>>Rgds
>
>He means that the file is encrypted and the bootloader program inside
>the PIC decrypts it before writing it to flash. 
>
>
>Best regards, 
>Spehro Pefhany

"Calvin Chan" <calvin_chan@post1.com> wrote

> That means the service engineer onsite owns a copy of hex code which
> we do not really want.

There is _no difference_ between 'hex code' and 'binary code'.  It's all
1's and 0's.

If the service man has the equipment to reprogram the system then
he _has_ the hex/binary/octal/trinary machine code.  A few minutes with a logic
analyzer and out she comes, all pretty printed and formatted.

I would re-examine the idea of secrecy.

As Mike pointed out you may be spending far more on security than it
would cost the competition to hire a few students to clone your product.

Unless, of course, your product is holding cipher data.  But if this is to be
a truly _secure_ product I think you have already 'screwed the pooch' by
allowing
unsupervised access to the hardware.

I agree with Mike and suggest you let the customer download updates
from the net as needed and forget about it.  You'll save a fortune on
Tylenol and Tums.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

Of course, I admitted that this is not a complete secure solution, but
it would be far better than bringing the .hex or .bin file around that
people can merely copy the file from the unattended machine, if the
service engineer let the machine unattended.  We tend to make thing
difficult rather than impossible.

This is one aspect that I am after the handheld programmer. The other,
is of course, as mentioned, is the odd position to reprogram.

Calvin 

On Fri, 17 Dec 2004 04:00:40 GMT, "Nicholas O. Lindan" <see@sig.com>
wrote:

>"Calvin Chan" <calvin_chan@post1.com> wrote
>
>> That means the service engineer onsite owns a copy of hex code which
>> we do not really want.
>
>There is _no difference_ between 'hex code' and 'binary code'.  It's all
>1's and 0's.
>
>If the service man has the equipment to reprogram the system then
>he _has_ the hex/binary/octal/trinary machine code.  A few minutes with a logic
>analyzer and out she comes, all pretty printed and formatted.
>
>I would re-examine the idea of secrecy.
>
>As Mike pointed out you may be spending far more on security than it
>would cost the competition to hire a few students to clone your product.
>
>Unless, of course, your product is holding cipher data.  But if this is to be
>a truly _secure_ product I think you have already 'screwed the pooch' by
>allowing
>unsupervised access to the hardware.
>
>I agree with Mike and suggest you let the customer download updates
>from the net as needed and forget about it.  You'll save a fortune on
>Tylenol and Tums.

Maybe you need to think about the AVR instead. That has a keyfob
programmer available. Some nice stuff for AVR and PIC on this site
https://www.kanda.com/productnews.php3.

One approach that is in use at hundreds of locations in the UK is
update by satellite. Data is embedded in the TV blanking interval and
decoders with AVRs pull out the code and can reprogram themselves. If
you choose a self-programming AVR then if you can get data to it then
you can reprogram it.

Peter

By using a "RS232 to Compact Flash" module, you could store the
programming data onto a portable memory card, rather than on a Laptop.

Avisaro (I work for them) build those modules:
www.avisaro.com/html/speicher_module.html

You can read and write file over the serial line (RS232) by using
simple "AT" commands. Like: at+open flash.s19 would open the file
"flash.s19" for read and with at+datastream the content of the file
will be send over the serial port. They use the standard PC file
format.

If you have a "self programming" part like Byron suggest, you could
connect the module more or less directly. Or you use a small controller
which contains the programming algorithm and which uses the RS232 to CF
module to get the data. A simple encryption algorithm could be
implemented in this case as well.

- Matt
You can contact me directly if you need an Englisch speaking person.

Kanda may be a candidate for what I am after.  But their PIC
programmer is currently under development and support only PIC18
series.  Our devices have both PIC16 as well as PIC18.
https://www.kanda.com/productnews.php3

It looks to me that we are likely to implement our own.  The
implementation involves using a MCU with 32K or 64K flash, eg.
atmega32 or atmega64.  First to  implement a hex file interpreter and
write the byte stream  into its flash.  Once this is done, the code
will be always ready to download to target by following the
corresponding ISP protocol.

Rgds

Calvin 

On 17 Dec 2004 02:42:18 -0800, "matt@avisaro.com" <matt@avisaro.com>
wrote:

>
>By using a "RS232 to Compact Flash" module, you could store the
>programming data onto a portable memory card, rather than on a Laptop.
>
>Avisaro (I work for them) build those modules:
>www.avisaro.com/html/speicher_module.html
>
>You can read and write file over the serial line (RS232) by using
>simple "AT" commands. Like: at+open flash.s19 would open the file
>"flash.s19" for read and with at+datastream the content of the file
>will be send over the serial port. They use the standard PC file
>format.
>
>If you have a "self programming" part like Byron suggest, you could
>connect the module more or less directly. Or you use a small controller
>which contains the programming algorithm and which uses the RS232 to CF
>module to get the data. A simple encryption algorithm could be
>implemented in this case as well.
>
>- Matt
>You can contact me directly if you need an Englisch speaking person.

In article <cqg4s0h4dbp9l9ooeg5gg6j539pndauvtr@4ax.com>,
Calvin Chan  <calvin_chan@post1.com> wrote:
-Byron
-
-That means the service engineer onsite owns a copy of hex code which
-we do not really want.

It can be encrypted, so without a way to decrypt, it's not very useful.

-  Also, the device is installed in odd area that
-bring a laptop and climb up long ladder is not a very nice way to do.

I didn't say laptop.

-
-Battery driven uploader is the ultimate goal.

So have one with a serial port. The idea is still sound. You can make it
somewhat more secure by using a different physical interface too.

The point is that you need a bootloader precisely because the PIC programming
interface is well known. A logic analyzer and access to the programmer gives
the holder access to the code. A bootloader allows you to define your interface
instead of using MChips standard interface.

BAJ