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 CCS Technical Support

Question about #build (reset=0X200, interrupt=0X208)

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



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

Question about #build (reset=0X200, interrupt=0X208)
PostPosted: Fri Sep 21, 2007 1:05 pm     Reply with quote

I'm trying to move the application reset vector and interrupt vectors out of the boot block.

#build(reset=0x200,interrupt=0X208)
#org 0X0, 0X1FF {} // don't use boot block

This compiles, but the interrupts are not working !

I just called CCS help and was told to use jump_to_isr() !
The latest help file has very little information on how to use this here is all it says: (with my comments:

int_global // what is this and where does it go ?

void global_isr(void) // does this replace the CCS generated isr handling ?
{
jump_to_isr(isr_address); // do I need to add a statement for every ISR ?
}

Lastly how do I get the address of the ISR ? is this done dynamically or at compile time ?
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Fri Sep 21, 2007 1:24 pm     Reply with quote

There's an example of its use in Ex_Bootloader.c.
It's in this location:
Quote:
c:\Program Files\PICC\Examples
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Fri Sep 21, 2007 1:57 pm     Reply with quote

The example is not clear about what happens to the original isr dispatcher.

Does this new isr() replace the isr dispatcher ?

The value LOADER_END+5 seems to be specific to the ex_loader example.
But what address do I need to use ?

Is it 00208: GOTO 02CE // the isr dispatcher (from lst file)

This is not clear at all.

#int_global
void isr(void)
{
jump_to_isr(LOADER_END+5*(getenv("BITS_PER_INSTRUCTION")/8));
}

I'm lost ...
Ttelmah
Guest







PostPosted: Fri Sep 21, 2007 2:47 pm     Reply with quote

The compiler generates the normal dispatcher at the 0x208 address (this is what the 'build' statement tells it to do). You need to jump the physical interrupt, to this address, with the routine placed in the bootloader code.

Best Wishes
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Fri Sep 21, 2007 4:16 pm     Reply with quote

Ttelmah wrote:
The compiler generates the normal dispatcher at th 0x208 address (this is what the 'build' statement tells it to do). You need to jump the physical interrupt, to this address, with the routine placed in the bootloader code.

Best Wishes

Not sure I understand that.
The bootloader is a separate program from the actual application. Not sure I see the connection.

Lets say there is NO bootloader involved, and all I wanted was to operate the program with build (reset=0200, interrupt=0208) and code left out of the boot block.

#org 0X0, 0X1FF {} // don't use boot block

Where does the jump_to_isr(address) go in the application code ?

Best regards
Hans W
Ttelmah
Guest







PostPosted: Sat Sep 22, 2007 2:09 am     Reply with quote

It doesn't.
To use interrupts, the bootloader, _must_ vector the interrupt jump, 'into' the real code. The following assumes only low priority interrupts are being used - otherwise two vectors come into play.
If you generate a program, with the build statement given, the compiler generates:
0x200 GOTO main_program_entry
0x208 The ISR handler

The hardware still generates a call to address 8 (this cannot be changed), so the bootloader needs to itself contain an 'int_global' handler, which just comprises a jump to address 0x208.
The bootloader code, must provide this relocation.

Best Wishes
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Sat Sep 22, 2007 8:20 am     Reply with quote

Ttelmah wrote:
It doesn't.
To use interrupts, the bootloader, _must_ vector the interrupt jump, 'into' the real code. The following assumes only low priority interrupts are being used - otherwise two vectors come into play.
If you generate a program, with the build statement given, the compiler generates:
0x200 GOTO main_program_entry
0x208 The ISR handler

The hardware still generates a call to address 8 (this cannot be changed), so the bootloader needs to itself contain an 'int_global' handler, which just comprises a jump to address 0x208.
The bootloader code, must provide this relocation.

Best Wishes

Thanks for the explanation.

I now see the reason why top end boot loaders are more popular, almost no code changes to the loaded program but at the price of exposing one's code.

About the high priority interrupts: In the PIC18F6720 the High Priority interrupt vectors starts at 0x0008 and the Low at 0X0018 .

So if I understand this the should be another jump_to_isr( 0x0218) to cater for the Low priority interrupts.

Am I correct in that assumption ?
Ttelmah
Guest







PostPosted: Sat Sep 22, 2007 8:31 am     Reply with quote

Only if you are using both.
If interrupt priority is disabled, the 08 address is used.

Best Wishes
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Sat Sep 22, 2007 8:47 am     Reply with quote

Ttelmah wrote:
Only if you are using both.
If interrupt priority is disabled, the 08 address is used.

Best Wishes


Yes I just noticed that.
I added #device HIGH_INTS=TRUE and tthe compiler generated this. To me it seems the one statement handles both.

Looks like the code handles the High Priority Interupts at 00008: GOTO 2008 and RETFIE's back into a few NOPs and then hits the low priority Interrupts and finally RETFIE's out at 0001C: RETFIE 0
I wonder if all those nop's are needed !

Thanks for the help I think I've got the hang of it now.
Best regards
Hans W

.................... void isr(void)
.................... {
.................... jump_to_isr(LOADER_END+5*(getenv("BITS_PER_INSTRUCTION")/8));
*
00008: GOTO 2008
0000C: NOP
0000E: NOP
00010: NOP
00012: NOP
00014: NOP
00016: NOP
00018: GOTO 2018
.................... }
....................
0001C: RETFIE 0
Guest








PostPosted: Sat Sep 22, 2007 9:45 am     Reply with quote

Yes.
The 'jump_to_isr' instruction will automatically handle both. This is the difference between using this, and a manual 'goto'.
What else are you going to put in the space between the jumps?. There is not enough space for any useable code, and nop is safe.
It doesn't "retfie back to the NOP's". When 'retfie' is executed at the end f the handler in the main code, the handler returns to where the interrupt occured. The address is on the stack.
The NOP's should never be executed.

Best Wishes
Hans Wedemeyer



Joined: 15 Sep 2003
Posts: 226

View user's profile Send private message

PostPosted: Sat Sep 22, 2007 4:48 pm     Reply with quote

Anonymous wrote:
Yes.
The 'jump_to_isr' instruction will automatically handle both. This is the difference between using this, and a manual 'goto'.
What else are you going to put in the space between the jumps?. There is not enough space for any useable code, and nop is safe.
It doesn't "retfie back to the NOP's". When 'retfie' is executed at the end f the handler in the main code, the handler returns to where the interrupt occured. The address is on the stack.
The NOP's should never be executed.

Best Wishes


Thanks for the help. This bootloader is also working fine and code is protected from reads.
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