Jump to content
emte

Bootloading From Eeprom

Recommended Posts

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 by emte

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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)

Share this post


Link to post
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...