#Locate auto=address usage. relocate scratch variables

[cdemetri]

Compiler Version 4.119
Target 18F6227


I have reviewed the past posts regarding relocating the automatically generated scratch variables.

Here is a snippet from my symbol file showing what scratch variables I am referring too.

The reason I need to relocate is I use high and low priority interrupts and I am finding situations where a high and low priority function share ram space which results in the low priority variable being corrupted.


<snip symbol>
E13 FlushDUARTB_RxBuffer.crit_sect
E13-E14 DU_INTB_isr.rtsched_tmr
E13-E14 DU_INTA_isr.rtsched_tmr
E13 FlushDUARTA_RxBuffer.crit_sect <LOW PRIORITY
E13 MngRTSCHED_TaskScheduler.@SCRATCH1
E13 IntrptTIMER1_Periodic10ms.@SCRATCH1 <HIGH PRIORITY
E13 IntrptUART1_Rx.@SCRATCH1
E13 IntrptUART2_Rx.@SCRATCH1
E13 IntrptUART1_Tx.@SCRATCH1
E13 IntrptUART2_Tx.@SCRATCH1
E13 timer3interupt.@SCRATCH1
E13 ManageDUB.@SCRATCH1
<end>

From previous posts I have found numerous ways to relocate user variables by declaring them as static or using the locate keyword. However I can not find a successful way to relocate scratch variables.

One suggestion was made to use #locate auto=address in the desired function. The documentation also mentioned this under the #LOCATE key word. However, when I try to use the line #locate auto=address I get quite a few errors. Error 28 Expecting an identifier.


It doesnt matter what I do, even an empty function generates errors.
*** Error 28 "d:\timers.c" Line 165(1,6): Expecting an identifier

void function ( void )
{
#locate auto=0x100
}

I do not have any ORG's in my code, and do not use the word auto anywhere in my code, perhaps this is the problem.

any ideas?

++++

1) I have confirmed that the ISR is not saving and restoring these variables. I am not referring to the ISR SCRATCH area at the bottom of memory. I am referring to function scratch registers.

2) I have confirmed that the low priority interrupt function variable is getting corrupted.

[PCM programmer]

[cdemetri]

Thanks for emailing CCS.
I have also emailed them about it.
Hopefully we can get an answer to this.

[Ttelmah]

If you want to get working, while waiting for CCS, the answer is to #ORG your high priority interrupt code.

If you work out the total size of your high priority code, and add:

#ORG 0x100,0x1000, default

in front of the first high priority routine, with the first number chosen to put the code somewhere down near the interrupt dispatcher, and the second chosen to leave enough room for all the code, then have all the high priority routines, and follow these with:

#ORG default
and the rest of your code.

Separate 'scratch' storage will be generated for all the high priority routines.
Downside is it means _you_ have to allocate the storage for the routines (the #locate option should leave this as automatic, only changing the scratch storage part), but it should solve the current problem. As a very crude example (using FP multiply as the routine wanting a separate scratch area)