CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

baffled by the bootloader

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
Piccolo



Joined: 19 May 2006
Posts: 23
Location: Connecticut

View user's profile Send private message

baffled by the bootloader
PostPosted: Wed Jan 10, 2007 4:56 pm     Reply with quote

using PCWH 3.249 with PIC18F6720

This is odd, and I hope someone can help.

I have a program that I load into the PIC via Epic programmer that writes some data to an external eeprom.
I have another program that I then load into the same PIC via Epic programmer that reads the data from the external eeprom.
so far, so good.
I then need to allow the user to change between the programs (in case the data written needs to be altered) so I implement a bootloader.
I place
[/code]#build(reset=0x200)
#build(interrupt=0x208)
#org 0x0000,0x01FF {} [code]
before the main of each program and compile both programs.
I install the first program via the bootloader and it installs and runs fine.
I then install the second program via the bootloader but it now does not read the data back anywhere near correctly.
If I load the first program (without the bootloader code using an Epic programmer)
and then load the second program either via the bootloader or via the Epic programmer it reads the data fine! I have no idea why this occurs.

The bootloader works fine for installing different versions of the second program.

Any idea where I should look to see why the second program cannot read the data?

I have searched the forum but have not found a match.
Any suggestions greatly appreciated.
Thank you in advance
ckielstra



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Wed Jan 10, 2007 5:29 pm     Reply with quote

Might have something to do with the #fuse settings, are these the same in all your programs?

All bootloaders have limited capabilities for the fuses; setting a fuse from the bootloader is no problem, but some (or all) fuses can only be reset by an external programmer performing a full chip erase. It was implemented this way to prevent changing of the memory protection fuses.
Piccolo



Joined: 19 May 2006
Posts: 23
Location: Connecticut

View user's profile Send private message

PostPosted: Wed Jan 10, 2007 11:59 pm     Reply with quote

Yes, both sets of #fuses are identical

#fuses NOBROWNOUT,XT,WDT128,NOLVP

except program 1 has
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,stream=UPort1)

while program 2 has
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,stream=UPort1)
#use rs232(baud=9600,parity=N,xmit=PIN_G1,rcv=PIN_G2,stream=UPort2)

but these statements are after the #fuses,
The bootloader always connects through UPort1.
Guest








PostPosted: Fri Jan 12, 2007 10:32 am     Reply with quote

What bootloader are you using?
Guest








PostPosted: Fri Jan 12, 2007 10:39 am     Reply with quote

Should your staement not be

Code:

#ORG 0x7000,0x7FFF {}

Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group