emte 0 Posted January 23, 2007 Report Share Posted January 23, 2007 (edited) Currently looking at building a custom bootloader that will load from an external EEPROM. Another mcu/device will be writting the hex into the eeprom. Wondering how many pitfalls i should expect to see. Edited January 23, 2007 by emte Quote Link to post Share on other sites
trossin 0 Posted January 23, 2007 Report Share Posted January 23, 2007 This should just work as long as you are using a device that can self write to internal flash memory. My guess would be: 1. At power up or reset jump to an internal boot loader at the end of memory. 2. In this boot loader, initialize communication to the external EEPROM. 3. Come up with a header scheme in the EEPROM so that the boot loader can figure out the starting address and size to load. 4. Enter a loop to read from the EEPROM and write to internal flash memory. 5. When the loop is finished jump to the desired starting address. Of course there is the standard ugliness of implementing a boot loader so that the application writer does not have to know it exists except when it comes to the fact that the code size has to be a bit smaller. Parts of a solution I implemented for a RS-232 port boot loader are shown below. Basically, I have my PC side software change the address for the first 4 locations of the application to the last 4 locations of the device I'm programming. This way I can keep my startup code in the first 4 locations. This works fine for code that uses interrupts as there must be jump in the first 4 locations or the code will hit the interrupt handler. For some reason I thought this also worked for the non-interrupt code case in SourceBoost but I just compiled some code and it sure does not seem like it will work any more as the code falls through from location 3 to 4. My code will not deal with this as virtual location 3 will fall through to physical 0. What a bummer. The work around is easy in that I'll just always specify an interrupt function but that bites. It does appear that if I change my boot loader (PC side) to write location 3 that the non-interrupt case will work again. Good luck. Check my web site if you want more detail. org 0 Startup: #ifdef MEM_SIZE_4K bcf PCLATH,4 bsf PCLATH,3; Page 1 #endif #ifdef MEM_SIZE_8K bsf PCLATH,4 bsf PCLATH,3; Page 3 #endif goto BootLoad goto Main ; ******************************************************* ; ** ** ; ** Main start of code ** ; ** ** ; ******************************************************** Main: goto Main ; Hang ; ********************************************** ; ** ** ; ** Boot Loader Code ** ; ** ** ; ********************************************** #ifdef MEM_SIZE_4K org 0x0f00 #endif #ifdef MEM_SIZE_8K org 0x1f00 #endif BootLoad: ; Your EEPROM loader here ; Jump to Cleanup when ready to run copied EEPROM code CleanUp: bsf STATUS,RP0 ; Select Bank 1 registers clrf TXSTA^0x80 bsf TRISC^0x80,6 ; PORTC[TX] is Input clrf SPBRG^0x80 bcf STATUS,RP0; Select Bank 0 registers clrf RCSTA goto JumpToMain #ifdef MEM_SIZE_4K org 0x0ffb #endif #ifdef MEM_SIZE_8K org 0x1ffb #endif JumpToMain: ; Last 5 words of memory clrf PCLATH ; Last 4 locations that will get overwritten by boot loader with the ; first 4 locations from the user program. bcf PCLATH,4 bcf PCLATH,3; Page 0 goto 3 nop Quote Link to post Share on other sites
emte 0 Posted January 25, 2007 Author Report Share Posted January 25, 2007 The standard serial bootloader is easy and there are many examples that abound, but thank you for your example. My only difference is that i initially just jump to my bootloader block at the end of memory and evaluate the bootload vs main choice and then jump back to main by default, maybe this will help your issue. The external eeprom method is part of a ... coupling idea for a mcu supervisor circuit. The supervisor will handle all the reception and writing into the eeprom, data integrety and proper device targeting, as well as control over when to initiate the bootload. There are a few reasons to do it this way but my primary one is that some of the protocols that will transfer the bootloader are too much overhead to have on the target datawise.(ie: ethernet and RF) Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.