bootloader that xfers code from I2C into program memory

[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]

Yeah well, at least I contributed SOMETHING! LOL

This is a major game-changer for field updates. The approach should also work fine for PIC16F88's.

I'll try to create a somewhat "generic" windows firmware updater based on this approach, with VB6 in the next little while and post it for others to use. It will only be able to Xfer a file IN (PIC readcode dump-->PC), and send a file OUT (PC-->PIC firmware update). It will NOT have encryption built into it, since that's also critically dependent upon a PIC decryption subroutine.

Did you manage to successfully pass variables from your "main program" to your "bootloader" section? If so, did you declare them in BOTH, or was that the purpose of your BLOCKSIZE declaration as a system variable, so it would be accessible for the upper memory AND the resident program?

Thanks,

picster

[pedja089]

I did, but via EEPROM and other way. So main app knows when it is first run, so it can configure I2C memory, etc...
But you can define variables at specific addresses.
From manual:
wsave VAR BYTE $70 'Creates "wsave" at RAM address 0x70 (hex)
Just create variable at address $70 both in main app and bootloader. And load it in main app before jumping to bootloader, and use it in bootloader. But you must be careful not to clear it, before use.

BLOCK_SIZE is ASM constant for each pic. And it tell how long is one block or page in FLASH.
So to get this information to PBP, I used this code:

@ MovLW BLOCK_SIZE ;move literal to W
@ MovWF BlockSize ;Move W to File(variable)

If variable is not defined as system

    BlockSize       VAR BYTE BANKA

    @ MovLW BLOCK_SIZE
    @ MovWF _BlockSize

BANKA must be used, or in ASM you need to set correct bank.
This can be done in few ways, but i don't like that. All my ASM routines use variables in BANKA, so I doesn't have to deal with selecting bank.
SYSTEM just removes underscore in ASM variable name. Default behavior of PBP is to put _ in front of name. Eg if you declare A var byte, in ASM variable is called _A. With modifiers SYSTEM PBP will create same name for ASM.
Just habit that I have to put all ASM variables to BANKA SYSTEM...
[EDIT]This also could be done with EXT modifier.[/EDIT]

FLASH is erased and write ONE PAGE at TIME. PBP will track address that you are writing, and when it align with page it will dump all data to FLASH.
Data are temporally stored to TBL. So if you just put one WRITECODE instruction, your byte or word wont be written to FLASH. It took me some while to get it. At least for PIC18F.
If you measure how much time it takes to do instruction WRITECODE, you will see eg 63 very fast(10-20 uS, depending on oscillator speed), and 64th will take about 5mS(doesn't depend on oscillator). This is if your page size is 64 byte. Don't hold me to exact figures, I can remember just ballpark value.

[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).