Customers Performing Own Upgrades. How Hard Can It Be?

I want to design into future products the ability for a customer to connect their product to a PC and run a upgrade file which re-programmes the product.

Having looked at the bootloader method, I think that could work in principal, but trying to get the customer running the Microchip bootloader programme is too complicated.

Attached is my concept schematic (untested) showing how I could take over control of the serial port from the normal circuit.

The tricky part is getting a GUI to perform the actions automatically.
Is there anything I should be looking at before I commision a GUI be written. Also any suggestions on the circuit would be useful.

Thanks,
Tim.

Dumb question, but why not use PIC with builtin USB and emulate a USB bootloader?

George

- Legacy with older products!
We use the 18F*6K22 and 18F*431 almost exclusively. If we were starting afresh, then we probably would use a built in USB port.

I you want this to be user friendly I don't think CDC (serial port emulation USB) is the way to go. You will find it problematic to determine which serial port (COM1:, COM2: etc.) is connected. I don't know the devices you currently use but porting to another PIC might not be as difficult as you expect. Provided that your code uses symbolic names for the various components inside the PIC and no magic numbers it shouldn't be that tough.
Why not try a port before you burn your bridges? I'm curious, could you list precisely which PICs you use of the families you mentioned?

George

I had a quick look at the data sheets of the devices you use, do you use the Motion Feedback Module in any of your products?

Sorry I can't edit my previos post.

Had a play with MAPS and I think I see your problem, the 18F*6K22 has a 12 ADC and 18F*431 has Motion Feedback Module. There are no PIC18F's with USB and Motion Feedback Module. There are however, 17 PIC18F's with 12 bit ADC and USB. If you are using the MFM then you have no choice but to go serial.

Most PC's don't have serial ports so that might help you find your emulated one. If not, you're going to have to ask the user or maybe trial and error?

George

We use the 18F26K22 / 46K22's because they have two serial ports and are backwards compatible with the 16F876/877 which we used to use. (albeit the analogue/digital configuration has to change)
The 18F2431 / 4431 (with motion feedback module) are used for motor control.

The MFM module tracks the quadrature counts (QC's) for position, and by using a known time interval, velocity. The Microchip velocity measuring module is a waste of space!

Sorry I don't follow, do you use the MFM in your app?

I can see why you are unwilling to port to another PIC but the downside of using CDC is substantial.

An alternative might be to add USB hardware to make a HID connection.

George

Quote:

---

... do you use the MFM in your app?

---

Eventually we would use it in future products requiring customer upgrades. At present it's a return to base upgrade.
I would like to get the *6K22 working first!

For a tipical individual that wants to upgrade the programming in their PIC, I don't think the Microchip Bootloader program would be that complicated for him. If you create a good tutorial with pictures on how to use the Microchip Bootloader, I think that that's the way to go.

@rsocor01 I suspect that the target user wouldn't know a PIC from a pick.

@timmers There are many PIC devices similar to *6K22 with USB builtin but I suspect you have already decided against porting. In which case CDC must look very attractive but I would suggest falsely so. Just a couple of ways that you can have HID, a cheap PIC with USB as a buffer or maybe MCP2210. BTW you do realize that USB bootloader is purely software.

Anyways, I leave you with this thought - CDC bad, HID good.

George

Perhaps I'm missing something. :?

Can you not supply or advise your customers to buy a cheap pic programmer and simply send them hex files.
The hex files could be zipped and password protected if required on an individual customer basis.

http://www.piccircuit.com/shop/pic-p...rogrammer.html

That's what I do. Same pic programmer covers all of my projects/products.
Even some very elderly punters have been able to cope with using pickit2 and the programmer.

Perhaps it's possible to use pickit 2 in a command line mode with file name in the script.

Yes you are. He's trying to find a method for a non-technical person to upgrade a "black box", to repeat myself - I suspect that the target user wouldn't know a PIC from a pick.

George

MikroE have nice little hid bootloader.
http://www.mikroe.com/img/developmen...der_window.jpg
It would be nice to have open source bootloader like that in PBP.

Hmm, if you send a hex file to your customer, how hard is to copy the circuit and use the hex on a new project, without you knowing it?

I prefer to keep my hex files really secret and away from any customer. Except if they have paid for it, and they own it.

Ioannis

If loader is open source you can easily add encryption. Then you send encrypted file to customer, application send encrypted data to pic(prevent someone to try find encryption in exe file, or to tap communication). Also you could use every 4th byte, load dummy bytes in encrypted file, write file from bottom to top, etc. So hex should be pretty safe...
Searching forum I found this http://www.etc.ugal.ro/cchiculita/so...bootloader.htm, and it should be good starting point for pic firmware. App for PC shouldn't be problematic, read byte from file then send it to HID or serial port, easily to do in VB6...
But I'm not still sure how to use loader with PBP, how to remap interrupt vectors, etc...
Only thing is that I don't have enough time to try it. I thing it should be doable...
EDIT:
If someone really wants your hex, then he'll just send one or two mcu from your device to company like this http://itresearch.weebly.com/services.html, and copy your board.

Thanks for your comments. The security aspect is concerning and I haven't decided yet on how to protect my hex files.

I think the next step is to connect my data reader to the RX TX lines and examine the sequence for Microchip's bootloader and a HID based system.

Not sure thats the best way to go about it. The USB enumeration process is very complex and mainly boilerplate (ie. unrelated to your situation). The volume of traffic can be quite overwhelming, even with a pukka USB analyser. Its probably easier to understand by looking at the code on the PC and on the PIC in tandem. One simple rule is that the device (PIC) will never send data unless requested by the host (PC). There are many software only tools that will display HID host/device transactions (just the data not the overhead).

George

Here's a thought. Thorsten Klose uses a MIDI interface as a serial port with a bootloader. It has several advantages: 1) cheap usb interface, less than $10 on ebay. 2) optoisolator to eliminate grounding issues between the pc and the device, 3) the MIDI interface is easy to access from the pc side.

just a thought.

Would epoxy on the PIC prevent someone from reading the PIC?

I remember we've had this discussion before.

Robert

Chinese read the wafer itself, by laser cutting the chip open. So, epoxy is a problem to them? I do not think so.

Happend to me before...

Ioannis