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
Using #ORG to ensure the location of code doesn't change

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



Joined: 30 Jan 2004
Posts: 0

View user's profile Send private message

Using #ORG to ensure the location of code doesn't change
PostPosted: Fri Jan 30, 2004 5:46 pm     Reply with quote
Hi,

I'm trying to reprogram the FLASH and EEPROM using the I2C interface of a PIC16F872.

To test that the flash and eeprom download are working, I created two builds, both with the same I2C ISR, but one build has some application functionality removed from it.

I can download the EEPROM and FLASH over the I2C interface, however when I try to verify the memory between the two builds, I'm finding that the I2C ISR, which handles the flash download is different between the two builds, even though I preceded this ISR with #org.
The differences are for example
MOVWF 24 vs MOVWF 22
MOVWF 25 vs MOVWF 23

I'm assuming that these are scratch variables inserted by the compiler?

Is there anyway to force these scratch variables to the same location in every build?

I'm concerned that if I upgrade the flash using the I2C interface, that the I2C ISR, which remains the same across reflashes, may be corrupting scratch registers used by the main program loop.

Any thoughts
Thanks
Ric
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Sun Feb 01, 2004 4:04 pm     Reply with quote
Quote:
I'm finding that the I2C ISR, which handles the flash download is different between the two builds, even though I preceded this ISR with #org.
The differences are for example
MOVWF 24 vs MOVWF 22
MOVWF 25 vs MOVWF 23

I suspect these lines of code are actually in the interrupt dispatcher
routine, which starts at address 0x0004. They're probably not in
your #int_ssp isr code.

I made a small sample program, to try to emulate your problem,
and it uses 0x77 and 0x78 as scratch variables in the actual isr.

Quote:
I'm concerned that if I upgrade the flash using the I2C interface, that the I2C ISR, which remains the same across reflashes, may be corrupting scratch registers used by the main program loop.

But do you care ? I presume that the i2c code, which is probably
located up at the end of ROM, is only used to update the main program
and the data eeprom in the PIC. When the updating is finished, I
presume that you jump to ROM address 0x0000 and thus re-start the
program. So it doesn't really matter if the i2c code trashed a few
variables used by main(), because you're restarting the whole program.
All of main's variables will be re-initialized when it re-starts.

If I've mis-interpreted this, then let me know.

Have you experimented with adding "AUTO = 0" to the end of your #org
statement ? I don't know if that would help, but you could try it.
Read the manual about the caveats on its usage (in the section on #org).
Guest
PostPosted: Mon Feb 02, 2004 9:35 am     Reply with quote
Quote:
I suspect these lines of code are actually in the interrupt dispatcher
routine, which starts at address 0x0004. They're probably not in
your #int_ssp isr code.

The different lines of code are in the I2C ISR, this is the only code that is common between the two builds. The reflash of memory is performed from within the I2C ISR, once the reflash mode is entered, I never exit the I2C ISR.

Quote:
But do you care ? I presume that the i2c code, which is probably
located up at the end of ROM, is only used to update the main program
and the data eeprom in the PIC. When the updating is finished, I
presume that you jump to ROM address 0x0000 and thus re-start the
program. So it doesn't really matter if the i2c code trashed a few
variables used by main(), because you're restarting the whole program.
All of main's variables will be re-initialized when it re-starts.

Yes, because I use the same I2C ISR for normal communication. And because I don't actually update the I2C ISR when updating flash, because it updates the flash, the I2C ISR remains common across reflashes.

....However maybe this would be the best way forward, to create a separate function which I call from the I2C ISR, to perform I2C reads and flash writes, and locate just this function at a common address. That way when I update flash, I don't care if I corrupt scratch variables. I need to see if I have enough spare memory.


Quote:
Have you experimented with adding "AUTO = 0" to the end of your #org
statement ? I don't know if that would help, but you could try it.
Read the manual about the caveats on its usage (in the section on #org).

I've tried using the AUTO=0 flag, the problem still occurs.

Thanks
Ric
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