How to stop the compiler initializing BSR of HP Interrupts?

[asmallri]

How do I prevent PCH 3.249 from inserting a MOVLB instruction at the start of the HP interrupr handler? The 18F family have a common problem with fast return stack corruption which I handle inside the HP handler but before it gets there the CCS code has already modified the BSR register.

I tried keeping the #device HIGH_INTS=TRUE but not decaling my HP handler to the compiler so I could put my own startup code in place but the compiler then assumes it does not need to use priority interrupts (despite the declaration above) and sticks the low priority code at 0x0008

[Ttelmah]

Have a look at the thread 'Using "FAST" interrupt on PIC18'.
The BSR change, was a 'bodge' added at about 3.237, because the compiler was assuming in some routines that the BSR had already been set. It fixed the problem, but added a one instruction overhead if not needed. There is a bodge solution in this thead, which doesn't quite work as shown, but can be fairly simply modified to work.

Best Wishes

[asmallri]

Trouble is I am using fast and the bodge fix makes it worse because there is no way around it to address the fast return problem on a large number of 18F series PICs. This is a real problem.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

I don't quite understand what you mean by the 'bodge fix makes it worse'. All the bodge fix does is relocate the interrupt handlers 'down' by the required amount, so that the extra instruction does not get called.
The problem with it, is that to make it work, you have to use your own 'int_global' handler, for the normal interrupts,and add the extra instruction to this (since the relocation affects both the high priority, and low priority handlers), and the address needed, is 6, not 7 as given in the thread. However it allows the extra instruction to be avoided with no problem.
I still though, suggest my other solution mentioned earlier, of just using #ROM, to place the rght byte sequence at address 8. This works fine for me.

Best Wishes

[asmallri]

The problem with the fix is that it corrects the high ISR and breaks the low ISR. There is no additional MOVLB at the start of the low BSR.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Ttelmah]

Which is why you have to use your own int_global handler. Just add a dummy instruction at the start of this, and you are away.

Best Wishes

[asmallri]

Duh! Thanks,
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[treitmey]

I'm a little slow on the draw this morning. Did he mean to "add an instruction" and the instruction is a jump which is the "global handler" and this jumps to the ISRs???

I just want to understand.

[Ttelmah]

You add a dummy instruction to the start of the int_lobal handler (can just be a NOP). Then you tell the compiler to locate the interrupt handlers one instruction below the normal starting address.

#build (interrupt=0x6)

Then the new int_global handler gets placed at address 0x16, and the high priority handler gets placed at 0x6. The hardware interrupt call, takes place to address 8, and 0x18, _skipping_ the unwanted instruction in the high priority handler, and also skipping the dummy instruction in the int_global handler.

Best Wishes