Allowing end customers to upgrade firmware via USB

[picj1984]

Hello,

I apologize in advance if this is not the proper place for this question. A little background - I've been developing products using the CCS compiler for over 10 years now and I've never dabbled with USB.

I'm developing a new line of products now and one thing I'd really love to do is allow users to be able to upgrade firmware remotely via USB if I decide to add features, make improvements, fix bugs, etc. I also want to be open to the possibility of adding other kinds of functionality with USB communication between a PC and my products.

It's not clear to me how to make this happen. I understand that some PICs have USB support whereas others do not.

I noticed in the dev kits that there are two options that interest me:

Option #1 – Switch over to a PIC that has USB compatibility: http://www.ccsinfo.com/product_info.php?products_id=usbkit

Option #2 – Seems there’s this Vinculum™ VNC1L chip that allows for a microcontroller to interface with USB devices as the master bus. So I could presumably add USB to pretty much any PIC. http://www.ccsinfo.com/product_info.php?products_id=usb_master I checked and this chip is pretty expensive.

The thing that is most important to me is to be able to have customers upgrade the firmware on the PIC in the product via USB. Will option #1 or option #2 (or both) achieve that for me?

I'd love to get this question answered as well as any additional applicable information. Or perhaps just nudging me in the right direction.

As always, any help is greatly appreciated!

[picj1984]

After a bit more research I think I'm going to go with option #1... using a PIC that has USB compatibility built into it.

That said, I'm still not sure if you can actually program a PIC using USB in this way... and that's vitally important to me.

I'll check back for an answer here, but I'll post back here if I figure it out before then.

[temtronic]

This...

[Ttelmah]

Honestly, doing this well will use a lot of code.

Much better to use a second PIC!.

Problem is that if you use a USB PIC, you will have to have a USB bootloader in the PIC. This will have to be larger than a basic bootloader to include some form of security checking, so you can either encrypt the data or at the very least have some other basic checking that this code is for this chip.

Much better to have a PIC that just runs this code, and then programs the second PIC using LVP. You then have the space to do proper security checks, and even if everything goes wrong, this chip will still be working, and can reprogram the main chip.

[benoitstjean]

If I may add a comment, I use the PIC24EP512GP806 device and an external FTDI (DigiKey p/n 768-1008-1-ND). One side ties to one of the PIC's UART and the other side to a micro USB connector on its USB side.

I then use TeraTerm as a terminal program for the FW upgrade.

I had to contact CCS support to get a working version of their bootloader code that can run on the PIC24 and they sent me three files: EX_PCD_BOOTLOADER.C, BOOTLOADER_PCD.H and LOADER_PCD.C.

The way it works is that you first compile the bootloader code and burn its HEX file in the PIC using whichever programmer you have (I used the ICD-U64) from CCS but also works with the PICKIT2 from Microchip.

In your "standard program" - your program - you must compile it with "#include <bootloader_pcd.h>".

While Tera Term is running and the PIC powers-up, I modified the bootloader to say "Hit spacebar 3 times to enter bootloader mode". In the bootloader, I have it setup so that there's a 3 second 'delay' during which time you must hit spacebar. When the spacebar is hit 3 times, then the bootloader kicks-in otherwise the standard program will run. In the case where you haven't loaded the "standard program" and only bootloader is programmed in the chip, then the device will just sit there since you haven't loaded it yet.

But when bootloader kicks-in after you hit spacebar 3 times, it will say "Drag file here" then you just drag and drop the standard program's HEX file from Windows Explorer to TeraTerm's window. The FW upgrade will start and upon completion, the MCU will reboot in normal mode (unless of course you press spacebar 3 times again). I've been using this code for at least 3 years if not more.

It does chew-up some space in your PIC because the bootloader takes-up some space but reserves a certain amount of space for your standard program. But since I use the PIC24, that's a non-issue because it has a LOT of space.

The way I had it setup originally was that my circuit had a button and if the unit powered-up while the button was pressed-down, then it would go in bootloader mode. I removed the button to cut costs and PCB real estate space. I *think* that it works on most PIC types but I didn't want to play-around the CCS code because it's much more than what I can handle and I didn't want to screw-it up.

I didn't post my code here because it contains some modifications for my circuit. But if you're really out of luck and need more help, send me a private message and I'll see how I can provide the code. This code was provided by CCS directly and it's not mine. I just need to find a bit of time to do a clean-up.

I run it at 115200Bps and takes roughly 2 minutes to do the upgrade which uses around 60% of the PIC's program space.

Ben

[Ttelmah]

A huge amount depends on the actual requirements.

In your case Benoitstjean, you are happy to distribute the raw .hex, in a readable form. Many people won't be prepared to do this, but will instead require some form of security/encryption. Obviously if this is needed it makes the loader larger, and means a custom update application has to be used. However in your case it does mean a standard bootloader can be used. I notice you save a lot of codespace though by using an external USB module. A lot simpler. Tull the complete needs depend massively on what has to be connected, and security requirements etc.. For instance I have one system which as well as Bluetooth and USB, logs data via GSM. This can be called on the GSM, and given the right command, then updates itself from a website automatically, with updates ranging from basic configuration, to full software. However the 'loader' part of this is larger than many PIC programs. This though allows easy software updates as well as custom reconfiguring for the customer's requirements.

[asmallri]

If you only need serial capability via USB then...

I tried PICs and, ATMEL and STM32 controllers with integrated USB bootloaders but have given up with this approach. Every time you reset the PIC or put it to sleep you break the serial connection to the PC. Some PC applications will crash as a result, others can be made to reconnect. If instead you use a USB-to-Serial chip (such as the CH340 which costs 35 cents per chip or 65 cents for a complete module) the USB stays connected to the PC, consumes no valuable PIC resources, does not require to manage or cooperate with the USB stack, life is so much easier.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

Yes.
You will see Temtronic here very much 'extolling' the advantages of an external USB module over the 'on PIC' USB. It requires much less code, and is often cheaper than using a USB PIC (especially if everything else in your software, can actually accept the internal PIC clock). It's one of those cases where this 'marvelous' ability, actually carries so much overhead, that in many cases a proper separate interface may actually be more reliable, simpler, & cheaper....
Caveat.

[picj1984]

[picj1984]

[Ttelmah]

You can't easily get C source code (though in fact there are applications to regenerate this), but it is directly readble as assembler, so you can see exactly what it is doing. You can also (of course), copy it. Makes selling 'rip off' products very easy...
What the decompilers do is generate code that will compile to give the final result, but it is (of course) undocumented. Does require work to make into modifiable code.
Re-engineering from assembler is not very hard at all, so if you distribute raw .hex, you are distributing your code.
Whether a company would find this worthwhile depends on how valuable the code is.

[picj1984]