bootloader that xfers code from I2C into program memory

[pedja089]

Great!
I started with led blink, and worked from there.
Good luck, and keep us posted

[picster]

Got an LED flasher working from I2Cread->writecode with the program that performs the update in upper memory per the above.

One subtle difference:

Writecode on a PIC16Fxxxx is word length, so has to be transferred 2 bytes at a time from I2C to ONE codespace address

this works fine, just reading data out of the i2c sequentially as WORDS from every 2nd location:

' Now get data from I2C and write it to codespace
for CodeAddr=0 to 13919
I2CAddr=2*CodeAddr
i2cread PORTB.7, PORTB.6, I2CControl, I2CAddr, [Instruction], I2Cerror
writecode CodeAddr, Instruction
next CodeAddr

Thanks again!

picster

[pedja089]

Great!
Did you try to play with VB?
I didn't leave copy of translated code, and I don't want to post whole code, because of encryption method I implemented on file and communication.
And now it would be too much to do to remove all code for that, and just recreate code for hex import.

[picster]

Yeah I already had a VB program I'd written for dumping data to the PIC to store in I2CEEPROM for lookup, so this is just more of the same. Encryption will be pretty simple to add.

Upper memory code to reprogram from I2C is sitting at less than 1k in size, and that's including LCD user prompts.

Nice. Very nice.

picster

[pedja089]

I think other users would appreciate if you share your work.
Thanks!

[picster]

I think you mean YOUR work!

Without posting a VB "updater" (which is going to be very application specific for this case), there's really not much to post.

The idea here is to create a "firmware update file" from a master, so it can be distributed in the field or wherever.

Suffice to say that if your main program has a hidden "dump all my code out via serial" subroutine, then you don't have to muck about with interpreting intel hex files, you just get raw code (instructions) from memory location A to memory location B from your "master" that you've updated with your PIC programmer (the upper memory program is always included with this).

Once you have that "master" file captured by a PC, you can send it back out its serial port to be intercepted by the "main program" on any unit to be UPDATED, and stored on I2C. After checking the checksum, then you call the "reprogram" code sitting in upper memory to rewrite all the lower code, stopping shy of the "tucked" upper subroutine location. Encryption is just a matter of manipulation at the PC end after receiving the original dump, and reverse-manipulation at the PIC end as you pull the words back out of I2C (before doing the codewrite).

[pedja089]

It didn't get to me that you can easily dump PIC code from programed PIC if you don't want to muck with hex.
That is great idea!

[picster]

See clarification below....

I think you mean YOUR work!

Without posting a VB "updater" (which is going to be very application specific for this case), there's really not much to post.

The idea here is to create a "firmware update file" from a master, so it can be distributed in the field or wherever.

Suffice to say that if your main program has a hidden "dump all my code out via serial" subroutine, then you don't have to muck about with interpreting intel hex files, you just get raw code (instructions) from memory location A to memory location B from your "master" that you've updated with your PIC programmer (the upper memory program is always included with this) -clarification: the MASTER chip always has the upper memory subroutine sent to it via the PIC programmer - however, the only part you "dump" (and codewrite in the field) is the part PRIOR to that subroutine!!).

Once you have that "master" file captured by a PC, you can send it back out its serial port to be intercepted by the "main program" on any unit to be UPDATED, and stored on I2C. After checking the checksum, then you call the "reprogram" code sitting in upper memory to rewrite all the lower code, stopping shy of the "tucked" upper subroutine location. Encryption is just a matter of manipulation at the PC end after receiving the original dump, and reverse-manipulation at the PIC end as you pull the words back out of I2C (before doing the codewrite).