Thank you all for reading my post. I was wondering if it is possible to do the following: I have a PIC18f26k22 which is bootloader capable. I am communicating over two of the above mentioned PICS w/ rfd21733 wireless modules. Can I load my new firmware into the first PIC and send it over the wireless (euart) to the second PIC to load the new firmware on that one as well? Or must I load the new firmware to each PIC separately?

Thank you for your help.

Peaches

 

I could wait to see if someone fairly familiar with your specific PIC answers your question in a helpful way, but until we see, let me mention a couple things.

Firmware is not software, and originally required hardware switches or "triggers" to enable "writes" at a minimum, some required removal and connection to specific hardware. Things change rapidly, so your own firmware/hardware combo may well have a far more convenient mechanism. You realize that software like OS and drivers require a specific, atypical process including re-boot to update, so true firmware should require at least that, for security reasons.

You may well be able to send the firmware update software to your second unit, have it store in a certain directory or chip, and do an update from it, but if changes to the firmware can be made entirely remotely, it should be viewed as bug or security fault of the existing firmware/hardware system.

 

Thank you all for reading my post. I was wondering if it is possible to do the following: I have a PIC18f26k22 which is bootloader capable. I am communicating over two of the above mentioned PICS w/ rfd21733 wireless modules. Can I load my new firmware into the first PIC and send it over the wireless (euart) to the second PIC to load the new firmware on that one as well? Or must I load the new firmware to each PIC separately?

Thank you for your help.

Peaches

Your PIC is 'bootloader capable' but only from the perspective that you can write to the flash program memory under program control in a protected block. To implement a bootloader you would have to implement a bootloader program in the PIC. That program would have to be a real PIC program that:
1) resides in the same flash memory that the downloaded program does
2) manages the reception of data packets, validates them and programs the flash memory blocks (that obviously do not include the bootloader itself).
3) knows when to run the bootloader vs. when to run the target program
4) can re-map or bit-diddle the interrupt vectors to re-direct interrupts from the UART between the bootloader and the regular code

The loaded program has to be linked to run at an address not occupied by the bootloader.
You will also need a protocol that accepts the Intel HEX output from the assembler/compiler that generates your code and knows how to assemble those packets into a program image and verify it before running.
Note that you will want the bootloader to occupy the Boot Block (000h-7FFh) and use WRTB to protect it.
The bootloader will have to be loaded using a conventional PIC programmer, there is no resident bootloader.

There are application notes that discuss bootloading but I am unaware of any canned solution. If you find one, post it.

Good luck!

 

You can theoretically "gang bang" firmware uploads to multiple devices simultaneously.
The tricky part is most bootloader clients require a hand shake to pace the the process and validate the checksum, etc.
How could you arbitrate this with multiple devices? it's tricky: a sloppy work-around is to have it shake hands with one master device, and let the others receive the same data, without explicit handshake. This has worked for me, but it's risky.

Be warned- getting bootloaders to work can be extremely difficult and frustrating- it's advanced level stuff.