standalone programmer for PIC?

PIC chips are relatively cheap, so why not program a bunch of chips at your shop and then the service rep would go and swap out the chip at he customers site. ZIF sockets would be a good idea. Then the rep returns the old chips back to the shop for another round of updating. Pretty straight forward.

Please don't toppost. ZIF sockets cost much more than PIC chips.

Our product is not to use dip package but soic and ssop package solder onboard, so the only possible easy way is the ISP method.

Rgds

Calv>Marlowe wrote:

I don't think that such a device is available but it wouldn't be difficult to design and make one. All it needs is a suitable MCU with an RS-232 port for downloading the code, an ISP programming interface, a pushbutton, a couple of LEDs and some software.

Leon

Sure this is the way to do it, but of course if I can get one off shelf, that save our development time to study the ISP protocol etc.

Failing that in getting one off shelf, then there comes the question of whether there is sample C code for the ISP implementation.

Rgds

Calv>> Hi Folks

The algorithms are available, implementing them in C or assembler would be quite easy.

Leon

There should be application notes for this on the Microchip site. The things I'd worry about are: All the external stuff you have to have to support it...switches, connectors, input protection etc. You don't want to zap the circuit hooking up the programmer. In fact, you don't even want to open the enclosure to upgrade the firmware. You gotta have available pins or a way to use pins that are already wired to something else. What's the state of the processor during the programming? If conflicting outputs get turned on simultaneously, you can make smoke.

For processors with a UART, I like the bootloader approach. You can put a couple of optoisolators in a box and hang it on the serial port of any laptop (that has a serial port). It's harder to kill an optoisolated port.

I'd also worry about the security of your code. If it's really, really secret...AND...it has high value...it WILL be compromised... When you weigh the cost of a service call against the value of the code, you might find that secrecy is VERY expensive.

As a test, give the processor external specs to a high-school computer club and see how long it takes them to generate code to duplicate the function. Secrecy might be moot.

It's easy to underestimate the logistics of field programmability by an order of magnitude or two. At Tektronix, I spent a bundle of money implementing management mandated requirements that sounded good on paper, but sent life-cycle costs thru the roof.

What do you have to do to support a critical update on 100 systems spread all over the world? 1000 systems? Unless you have Santa Claus on the payroll, it's a real problem with a manageable inventory of programmers and personnel.

Field programmability really shines when the customer can do it all by hisbadself without opening the box. Take a lesson from computer motherboard, modem, ethernet, and most everything else, BIOS updates.

mike

-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

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

Calvin Chan wrote in news: snipped-for-privacy@4ax.com:

Please, no top posting. Ensure your design conforms to the ICD-2 in-circuit programming requirements. The ICD-2 is made by Microchip.

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

Calv>>-Hi Folks

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

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

Calv>>

"Calvin Chan" wrote

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

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.

Calv>"Calvin Chan" wrote

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

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:

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.

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

Calv>

-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