source code for updating firmware remotely

[treitmey]

I AM GOING INTO NEW TERITORY IN THIS ENDEVER.

But what I'm looking for is a way to update my firmware remotely.

I can send a file to my pic18F452. So I though to myself,...

Why not upgrade firmware to customers this way?

Anyone try this before? I was thinking of ripping apart a bootloader program and then "roll my own" from there.

But I don't know where to start. Any suggestions, or source code that I can rip appart.

Thanks in advance.
tjr

[valemike]

Look at microchipc.com

They even have a link where you can encrypt your .hex file so that the end user can't pirate it.

If you want to roll your own, looks like you'll need to do some windows programming as well. That's the stuff that I haven't touched since getting out of school.

[bdavis]

How do you talk to your PIC? ie: RS232, USB, CAN, I2C, TCPIP, etc - Typically, your customer or whoever, may have to connect something from the PIC to a PC so you can program it. This is typically a serial cable. I was thinking of using scripts with Tera Term Pro in conjunction with a bootloader for a quick and easy FW upgrade. It depends on how you write your bootloader also...

[treitmey]

bdavis:
I am using a RS485 with a proprietary protocol. MAX485 device.

Getting the data into the pick isn't the problem. I just don't know where the data goes and how it is formatted.

My RS485 routines use an interupt. It use this and store the data to my LCD. ( it has lots of mem and is read without a int). Then I will shift to progm. mode and read from LCD and write to ???


My original problem was that you can't prgm the pic unless the IRQ is disabled. I think I got around that one now. Just need to know the layout of the data for programming.

[treitmey]

Bdavis:

Also look at codeloader.c

It is free, ... just need to include the source header copyright (c) in your code

[treitmey]

ALSO worth mentioning,... is that the eprom writing is slow ie:
disable_interrupts(global);
write_program_eeprom(address, value);
delay_ms(4);
enable_interrupts(global);

taken from a different post

looks like i need to delay by 4mS

[bdavis]

I think I may now understand what you would like to do.

1.) If you need to service interrupts via RS-485, then you need to put in some flow control to stop the flow of data into the PIC. Sounded like you already have that issue solved. I don't know how much data your LCD can hold, but I would think it would be easier to not use the ram in the LCD to double buffer, unless you don't have an extra 64 bytes of ram in the PIC.

2.) I have done some looking around on bootloaders, but haven't done a custom one for the PIC yet. I think that you should be able to modify CCS code. If not, Microchip has bootloader code, and I found several others on the internet. From the looks of the one from CCS, you should be able to modify it to read from another source (LCD or RS-485).

3.) Is there a specific part of the bootloader that is giving you a problem?

[Mark]

Bootloaders work by going into a "special mode" . They are usually confined to a block of memory that never gets updated. It doesn't really matter how much RAM your program uses because all of the RAM is available to the bootloader since the normal program is not running. Also goes the same for your RS485 routines. The bootloader will have its own receive and transmit routines, usually not interrupt driven. Blocks of data are sent to the PIC, the PIC then writes these values. The PIC could then send back an ACK to signal the host that the writing is complete. Take a look at Microchip's App note http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en012031 it also gives you the ability to read the data back to verify what is there.