Jump to content
Sign in to follow this  
gbgb

Problems With A Bootloader - Programming The Application

Recommended Posts

Although this is not specifically related to BoostC but rather to the PIC itself, I hope somebody here can provide the answer.

I am writing a bootloader and having some trouble with writing the application into the memory.

The PIC is 18F6527 (18F8772 family).

The bootloader itself resides in the top of the eeprom (using the -rb flag) with only the two boot vector bytes at 0000 having a GOTO instruction to invoke it on reset.

The intention is that the application will not be remapped and will reside at the bottom of the memory (i.e - excluding the two boot vector bytes it will effectively start at location 0004). Note: - In the programming area of this site there is a bootloader for the 16F family following this concept.

According to the PIC datasheet, you can only prgram 64 bytes at a time.

As long as I program the application to a location statrting at address greater than 64 it seems to be programmed OK, but if I try to program it to starting at address 0004 nothing is programmed, and it also erases the two bytes at location 0000.

Except for writing in 64 bytes blocks, do you also have to write at address starting on 64 bytes boundries?

How would one program the application into the lowest memory range?

Or - must I relocate the application to higher memory and have the bootloader reside in the bottom of the memory?

Share this post


Link to post
Share on other sites

I've just read through the programming sheet for that device and it seems a bit vague. It doesnt explicitly state that blocks must start on a byte boundary but looking at the diagram on page 16 I am guessing you have to.

 

You could try embedding the jump vectors into your code so the get rewritten when you load in the application. You can do this using the #data pragma.

Share this post


Link to post
Share on other sites
I've just read through the programming sheet for that device and it seems a bit vague. It doesnt explicitly state that blocks must start on a byte boundary but looking at the diagram on page 16 I am guessing you have to.

 

You could try embedding the jump vectors into your code so the get rewritten when you load in the application. You can do this using the #data pragma.

 

You absolutely have to write on the correct boundaries - the datasheet is quite specific about this, by saying that only the upper bits of the memory address are used. Note that on some Pics the erase chunks and write chunks are not necessarily the same - and this varies from Pic to Pic!

 

Have a look at the PicPack library, which includes a bootloader, at embeddedadventures.blogspot.com

 

Enjoy.

Ian.

Share this post


Link to post
Share on other sites

Thanks for both.

 

Reading the fine print it is understood that one must write in 64 bytes boundaries.

Misunderstanding may happen due to the fact that the various bits of TBLPTR point to different entities in erase/write operations. While bits 0-5 of TBLPTR point to the program memory holding registers, bits 6-21 point to the memory space. This is briefly mentioned in the section that covers the TBLPTR (and ends with "for details see section - writing to flash program memory"). When describing in detail the write operation this is not mentioned at all and the only "warning" given is that code must be aligned to even bytes.

 

I do not like the idea of the application "stepping over" the boot vector area because any problem during this operation, or corrupt data, will leave you with a dead PIC. I guess I will opt for remapping the application and having the bootloader at low memory.

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...
Sign in to follow this  

×
×
  • Create New...