Firmware Options

[Mark_R]

Hi,

I have a hunch this may have been discussed on here ad nauseam but I can't seem to find the answer, so here goes...

I'm trying to determine what options I have for providing for a firmware upgrade on a (18F) PIC based project. I'm talking about an upgrade that would be done by the customer in the field. I anticipate that the product we are creating would have feature enhancements down the road that we would want to offer an upgrade path to. I would prefer a hardware based option, but would like to hear about the software options for the learning aspect.

By hardware option I mean something like an EEPROM in a socket that the customer could change in the field. (maybe it's as simple as sending a whole new PIC?)

By software I mean anything that requires a laptop / downloading / Etc. My target customer base (plumbers, electricians, Etc.) is unlikely to have a laptop readily available, and that seems like a support nightmare anyway.

If it matters, the project is planned as SMD.

Curious as to how this is typically done.

Thaks.

 

[Papabravo]

I would consider a micro-SD card as a firmware upgrade option. The SPI interface is easy to deal with, and there are SMT sockets. This presumes that the 18F can update it's own program memory. The system would work with or without the micro-SD card. If it is absent then the onboard code is a go. If it is there, but identical to the on board code the SD card is ignored. If the SD card is there and it is newer then an update takes place.

If the PIC won't allow an in system program memory update I'm sure the Atmel rep will be glad to explain how the AVR might be of interest to you.

 

[blueroomelectronics]

All 18F PICs support self programming. An SD card is a good end user option.
Google tiny bootloader
for idea on how the code looks for self programming.

 

[Papabravo]

All 18F PICs support self programming. An SD card is a good end user option.
Google tiny bootloader
for idea on how the code looks for self programming.

Thanks for that Bill. I thought they did, but I wasn't sure.
One minor annoyance will be the realization that the most cost effective micro-SD card may have 4GB-8GB of memory which is several orders of magnitude more memory than you will ever need for firmware upgrades on a PIC18F.
Another potential problem is that your firmware may be exposed to disassembly and reverse engineering.

 

[Mark_R]

If the SD card is there and it is newer then an update takes place.

Thanks,
So inserting the SD will result in a permanent upgrade? (a transfer) or will the system revert to the on-board program when the SD is removed?

Since current prices on SD's are more than the PIC itself, what about sending a new PIC and have it in a socket, or is that not typically done?

 

[Russ Hensel]

I would use a dip and swap out the chip. The returns could be reprogrammed. If surface mount swaping a chip is out and you need field re programming. You will have to decide which trade offs look best to you.

 

[Papabravo]

Thanks,
So inserting the SD will result in a permanent upgrade? (a transfer) or will the system revert to the on-board program when the SD is removed?

Since current prices on SD's are more than the PIC itself, what about sending a new PIC and have it in a socket, or is that not typically done?

Don't know about other people. You have to do what makes sense for you and your organization. You could download files over the internet and pipe them to your devices using a serial port boot loader if you like.

Sockets for SMT chips mostly negate the reason for using those SMT chips in the first place. If you find a micro-SD card expensive check out the Emulation Technology website for SMT sockets.

On another subject you referenced the folks who would be changing the chips. Are you seriously considering trying to train them in static electricity awareness so they don't destroy either of the chips they will be handling. I don't think you are looking at the economics correctly. At the time of manufacturing the cost is just the SD Socket.

The cost and the ability to upgrade is then balanced against the utility of that upgrade. Gotta make sure the charges are in the correct column -- accounting wise.

 

[Oznog]

Micro-SD is fine, but be aware that the program will itself reside on the PIC chip. Programs cannot be run off the SD card. The self-programming function of the PIC must be able to read the SD card's file and program it onto the chip. Preferably not automatically because you don't want to have it reprogram itself every time it turns on. It's a touchy process, a bit slow, a power glitch during self-programming will scramble the ROM, and the PICs have a limited reprogramming endurance.

You'll probably use a "secret" user input- like holding down the A and B button at the same time while powering on- to run the PIC in bootloader mode which does nothing but read off the SD card, program it into ROM, display "ROM updated" on the screen or whatever, and restart.

You want to make the bootloader be what reads the A & B button thing during powerup as a separate piece of code in a write-protected Bootloader block. That way, even IF the power is cutoff before the ROM is completely written, the ROM is screwed and the main program can't run but the bootloader ROM will not be affected, all you have to do is cycle power with the A & B button held again and have it retry the load off the SD card.

Get the bootloader right, because generally it's impossible for a bootloader update in the field to be able to rewrite the bootloader code itself. Not only would that defeat the goal of keeping the bootloader block safe from corruption from bad programming cycles (which would brick the device until you could plug a proper ICD into the header), but the code can't write the block the code is in without some very special tricks to ensure the memblock being written is not pointed to by the program counter.

Be aware that once you distribute updates this way, you cannot easily protect the code itself. The code is a code image file on the micro-SD card you gave them. That can be read back with a file reader and disassembled to clone your product. Contrast with sending them a socketed chip with the Read Protect fuse bits set- even if you plug that chip into a PIC programmer, you can't read back the program space (although, for the highly advanced hacker, it is sometimes potentially possible to defeat this feature). They cannot clone that chip into an identical chip, nor can they disassemble the code to figure out what secret algorithms you might have used.

Socketed chips are difficult for non-engineers to insert (bent pin 50% of the time), unless it's one of those PLCC sockets. Those are a bit expensive, fairly tall profile relative to an SMD, the number of chips available in such a package are less common, and even still you're not gonna want some nontechnical monkey rubbing their shoes on shag carpeting and sticking his finger in that while trying to bang the old chip out with a screwdriver.

 

[geko]

Be aware that once you distribute updates this way, you cannot easily protect the code itself. The code is a code image file on the micro-SD card you gave them. That can be read back with a file reader and disassembled to clone your product.

Actually if this matters you can run the data through an encryption routine prior to writing it to the SD card and then within the bootloader code decrypt it. Even a fairly simple algorithmn can prevent casual cloning.

 

[Mark_R]

I don't think you are looking at the economics correctly. At the time of manufacturing the cost is just the SD Socket.

Good point, I did get the bean-counting wrong. I'm liking the $1 SMT SD card socket. The cost of the SD card itself would be charged to the customer (if and) when the upgrade ever happens. I see that the sockets have a "card present" switch, which could be used to initialize the boot loader routine.

Actually if this matters you can run the data through an encryption routine prior to writing it to the SD card and then within the bootloader code decrypt it. Even a fairly simple algorithm can prevent casual cloning.

I think this is the way to go. I'm not overly concerned with cloning, but no sense handing the code over on a silver platter.

Anyone have any resources to study up on simple encryption algorithms?

Thanks.

 

[Pommie]

Actually if this matters you can run the data through an encryption routine prior to writing it to the SD card and then within the bootloader code decrypt it. Even a fairly simple algorithmn can prevent casual cloning.

An encrypted file can still be copied on any PC. The way to prevent piracy is to serialize each pic so only an upgrade with the same serial number will work or use some kind of timestamp type encryption. Does the device contain a real time clock?

Mike.

 

[Mark_R]

An encrypted file can still be copied on any PC.

I don't see how that will help someone, they won't have the hardware to run it. This is a piece of equipment that is close to $1K. Developing the hardware would be where the money is. The code is trivial. (hell, I'm writing it )

The way to prevent piracy is to serialize each pic so only an upgrade with the same serial number will work or use some kind of timestamp type encryption. Does the device contain a real time clock?

Mike.

Yes and no. There is a hardware RTC chip, but its not being "Set" to a real time. I need to have events happen once a day / week / month so I'm using the elapsed time counter feature. The actual TOD is irrelevant. There is no battery / supercap to maintain time, (not even any code to set it for now) When the system powers up I just kick the RTC with a generic time, like 01/01/2000 and let it run.

There are plans for a future version where the RTC would be needed. I have the SMT pads for a coin cell, but not populating at this time.

Thanks

 

[Papabravo]

One other point I forgot to mention. A minimally adept customer might need only 1 micro-SD card to update multiple units, further reducing the cost impact if some fraction of your customers have multiple units.

Google Search terms include "PGP" which stands for Pretty Good Privacy and "RSA" after the inventors Rivest, Shamir, and Adelman. They may not be the latest and greatest, but as you said they will impde the casual cloner.

I am working on a similar project in the consumer audio arena and I may have some bandwidth available to contribute to the specifcation, design, and testing of either the hardware or firmware.

 

[Mark_R]

One other point I forgot to mention. A minimally adept customer might need only 1 micro-SD card to update multiple units, further reducing the cost impact if some fraction of you customers have multiple units.

Google Search terms include "PGP" which stands for Pretty Good Privacy and "RSA" after the inventors Rivest, Shamir, and Adelman. They may not be the latest and greatest, but as you said they will impde the casual cloner.

I am working on a similar project in the consumer audio arena and I may have some bandwidth available to contribute to the specifcation, design, and testing of either the hardware or firmware.

Thanks for the ideas, I'll go do my homework now.

 

[Oznog]

PGP is a really common but effective strategy. However, you will need to be able to implement the decoder IN THE BOOTLOADER. This may be a problem to fit into the protected bootloader block, and may even be too numerically intensive for the PIC to implement at all.

The illegal copier guy would need to know how it's encoded, and have the numerical key for the decoder. And you'll keep that key in a read-protected part of the ROM. In PGP, even IF you know the decoding alorithm (like a copy of the bootloader code, if you grabbed a solution off-the-shelf), and a copy of the encrypted image file, there'd be little practical way to decipher the key and the image file even if he had the bootloader program without the specific key used.

IF he could get the bootloader you used, and a key, he's be able to self-program any updates you issue to any number of cloned chips and you'd never be able to stop him unless you physically issue chips with a new key to customers and stop providing updates which use the old key.

Of course you could always homebrew a "dumb" encryption method, such as swapping the even and odd bytes and then inverting every 3rd byte and adding +7 to every 4th byte. A cryptographer could figure that out fairly quickly if he searched for a text string known to show up on the display (thus almost certainly exists in ASCII form in the decoded ROM image) but an amateur would be hard-pressed to figure this out. Nobody said it had to be elegantly powerful, only to discourage casual piracy.

 

[Mark_R]

>>>> skill required to get this done
^
^
^
^ (Note the big gap)
^
^
^
^
<<<<< me

The encryption idea sounds cool, but I think it's a bit (OK, WAY) over my head at this point.
Trying to get the SD card bootloader off the ground will be daunting enough. Off to read some more.....

 

[Papabravo]

>>>> skill required to get this done
^
^
^
^ (Note the big gap)
^
^
^
^
<<<<< me

The encryption idea sounds cool, but I think it's a bit (OK, WAY) over my head at this point.
Trying to get the SD card bootloader off the ground will be daunting enough. Off to read some more.....

That is why I offered to help you; you seem like a good fellow with a boatload of problems, not to mention time pressure to produce.

 

[Mark_R]

That is why I offered to help you; you seem like a good fellow with a boatload of problems, not to mention time pressure to produce.

Much appreciated.

As you probably pieced together, my current PCB layout (still in CAD) is built around a CUBLOC controller ==> Comfile Technology Inc.

The various portions of the hardware and the code have been prototyped and worked out but the choice of the CUBLOC keeps nagging at me. I like the product and have some experience with it but keep coming back to 3 roadblocks;
1.- No ability to offer firmware upgrades
2.- If I want to outsource the software engineering at some point down the road as this product develops, I would need a mainstream controller.
3.- Unknown reliability of supply for the CUBLOC part.

So, I'm ditching the CUBLOC and jumping into the PIC world with both feet. I've read a lot and think I get the gist of how things are done. I have a programmer and PIC due in any day now to proto with. I'll try some stuff out and be back with the inevitable questions.

Thanks again

 

[Pommie]

I don't see how that will help someone, they won't have the hardware to run it. This is a piece of equipment that is close to $1K. Developing the hardware would be where the money is. The code is trivial. (hell, I'm writing it )

I assumed that you were going to charge for the future upgrade and was trying to point out that an encrypted file can be passed from Paul the plumber to Bob the builder very easily. You could find that a company with 50 employees would buy 1 upgrade and use it 50 times and then post it on the internet. Encryption without serialization will not stop this.

You state you are using an RTC. If you use a Dallas one wire device then these have a serial number built in and could kill two birds with one stone.

Mike.

 

[Mark_R]

I assumed that you were going to charge for the future upgrade and was trying to point out that an encrypted file can be passed from Paul the plumber to Bob the builder very easily. You could find that a company with 50 employees would buy 1 upgrade and use it 50 times and then post it on the internet. Encryption without serialization will not stop this.

You state you are using an RTC. If you use a Dallas one wire device then these have a serial number built in and could kill two birds with one stone.

Mike.

The equipment talks to a server. The biggest reason for an update would be in the event that we have to make a change to the location of or format of the server. Not really intended as a revenue stream. In fact, having a customer able to update all their units with the same chip would be a bonus.

Now you have me thinking... perhaps a hybrid approach would make sense. There could be a "serial number required" flag in the firmware file, where some updates (like a server change) would work on any unit, but a billable new feature would only work on a given target unit. I think I like that.

I am using this RTC ==> **broken link removed** It has on board EEPROM for S/N and other configuration data

Thanks for the ideas. good stuff.