Make a Firmware Update Tool

mfeinstein · Joined: 05 Jul 2012 Posts: 35

Hello guys!
I want to make Firmware Update Tool, and thus be able to change the code of a PIC, just by connecting the PIC to the PC with an USB cable and loading a file through a software interface on the PC that will change the code inside the PIC. At first I thought about a simple C function that will receive a block of bytes through the USB and change the PIC memory, replacing its contents with the bytes received....but then I realized that some time it would change the own function too, and everything will lose control...it's something like a bootloader, but not that much alike...my question is: Which is the best approach to this problem, and will I be able to code it on C, or only Assembly?
Thanks guys, you are my heroes!

RF_Developer · Joined: 07 Feb 2011 Posts: 839

Yes, it IS a bootloader: a USB bootloader. Bootloaders are generally written in assembly, its usually "simpler" (but more difficult), and certainly shorter and better suited to the resources of most PICs. Though USB really benefits from C, and there is good USB driver firmware available to speed the job.

There are plenty of bootloaders out there, many free or low cost. Even if they cost they will generally save you a lot of money in the medium to long term as its expensive and difficult to reinvent the wheel.

One question: is this a commercial project? A student project? Just a project you are doing because it sounds 'cool'? If you're doing this for real, then a ready made bootloader is the way to go. If you're a student then, well, you can't afford to buy a bootloader so you'll be best off with a free one. A fun project? Well, it all depends on what your idea of fun is? Personally struggling with code loading is not my idea of fun. Your milage may vary.

RF Developer

Ttelmah · Joined: 11 Mar 2010 Posts: 19498

I think it is key to understand that 'bootloader', is a very generic term. Historically, the true 'bootloader', was triggered during 'boot', and allowed the main code to be updated, while it sat either at the very bottom, or very top of memory, and protected _itself_ from being overwritten. The 'end' of memory chosen, depended both on personal preference, and the architecture of the chip. So chips that had (for example) their reset vectors and interrupt tables at the top of memory, 'tended' to go with high memory loaders, while those with these at the bottom of memory, tended to put the loader here.
It is possible to use either end of memory with each type of chip, but adds complexity.
On the PIC, the vectors are at the bottom of memory, and the hardware in many chips has the ability to implement 'write protection' on a small area at the bottom of memory, making this the 'preferred choice' for the PIC.

Now, though the term 'bootloader' is retained, it is perfectly possible to have these execute as 'in code loaders', rather than during 'boot'. Normally with the 'bootloader', you use something like an external jumper on the PIC to trigger the code to run. However it is perfectly possible to have a variable in memory, that defaults on the power on cycle to (normally) perhaps 0xFFFF, into which from your main code, you put a special 'unlikely to happen by accident' value, like 0xAA55, and you then trigger a chip restart. The code at the start of the 'loader' then says 'ah ha', 'loading required', and executes, instead of jumping straight to your normal code.
Now, if you look at the loader examples, you will find that they usually have their 'end address' recorded as something like 'LOADER_END', and when loading code, check it against this address, and if it is below this, don't load it. This avoids the problem "changing it's own function".

So what you are describing is still generally referred to as a 'bootloader', but is triggered by some event in the main code, rather than the 'boot'. However the basic design remains exactly the same, except what triggers it, and just as with the 'bootloader', the actual loading code, needs to be a separate 'entity', which protects itself from being replaced.

Best Wishes

Gabriel · Joined: 03 Aug 2009 Posts: 1067 Location: Panama

What PIC are you using?

The 16F877A and 16F88 have PLENTY of bootloaders out there...Google?

Sparkfun had/has one for the 16F88 and even wrote a PC program that loads the code onto your PIC, I believe it was called Code Screamer or somthing like that...

G.
_________________
CCS PCM 5.078 & CCS PCH 5.093

mfeinstein · Joined: 05 Jul 2012 Posts: 35

RF_Developer, I am a student, doing a student project for a lab in my university, so free is the way to go! :D

Gabriel, I am using the PIC18F2550

Ttelmah, as usual you are right ; ) , and that's why I said "something like a bootloader", because it isn't going to be triggered at boot time.

Is there any way to make it on C? saying to the CCS compiler where to place this particular piece of code (and the libraries as well, so it will function over the USB)? I dont want to write on Assembly, specially the USB part of it, and since I need it to work with my PC interface, I dont think there is any free code out there that will "fit" my interface...

Ttelmah · Joined: 11 Mar 2010 Posts: 19498

You do realise there is a complete USB bootloader with the compiler - ex_usb_bootloader.c?. If you look at it's 'main', you will see it decides to run the loader or not, based on calling the function 'button_pressed' (triggered by A4 being low). All that is needed is to change this decision based upon triggering this from your code, instead of the button.

Best Wishes

mfeinstein · Joined: 05 Jul 2012 Posts: 35

Ttelmah, I didn't look over all the example codes, that's a great tip! Thank you once more!
I am not with my CCS compiler here, so I can't see the code right now...may I ask you how do I "connect" with the bootloader? I mean, I can trigger the USB bootloader changing the "button_pressed" function, but how does the bootloader get the new code to be transfered? How do I give it to it?
Best Regards

Ttelmah · Joined: 11 Mar 2010 Posts: 19498

'As written', the example, accepts a hex file sent using the transmit function from a package like hyperterm.

Best Wishes

mfeinstein · Joined: 05 Jul 2012 Posts: 35

Humm...Hyperterminal has a Serial interface..I wanted to do everything over HID USB...I am traveling right now, as soon as I am back home I will have a look at this code

Ttelmah · Joined: 11 Mar 2010 Posts: 19498

USB CDC devices, are handled by Hyperterm etc., just the same as 'real' ports.

If you want to use your own USB interface, then you'll have to write the PC program as well.

Best Wishes

mfeinstein · Joined: 05 Jul 2012 Posts: 35

But they require special drivers, right?

Ttelmah · Joined: 11 Mar 2010 Posts: 19498

Not quite sure what you are actually asking.
The USB CDC device is handled by the standard Windows driver for this. All that is needed is a .inf file, to tell Windows to use the standard driver for the VID/PID of your PIC device (depending what you set this to).

If you want to load code through any USB device, Windows is going to need a driver to talk to it, and your code is going to have to talk to this driver. For 90% of 'standard' devices, Windows has drivers already.

Best Wishes