FAST Interrupt Problem - Compiler generating wrong code

[webbone]

PIC18F8722 Processor - CCS Compiler Version 3.324

I've been using the FAST option (with #device HIGH_INTS=true) for the RTCC interrupt on several designs and have had no issues.

Unfortunately for a new design I ended up switching from I2C to SPI for inter-processor communications, and due to layout constraints I used SSP port 2. I say unfortunately due to the fact that the compiler suddenly decided that both the RTCC and SSP2 interrupts are high priority and is no longer creating a FAST interrupt for RTCC.

Since there is no way to force the compiler to assign an interrupt to LOW priority I seem out of luck (which is bad since this design will not function if normal context handling occurs for the RTCC interrupt).

Does anyone know of an undocumented method to force an interrupt handler to low priority?

Or asked another way, is this just a bug in the compiler wherein it forces SSP2 to be high priority regardless of my wishes?

Worth noting, I have two other interrupts, Timer1 and RDA - previous design had everything the same except for using SSP port 1 rather than 2.

UPDATE: I tried changing the code to SSP1 rather than SSP2 and lo and behold the compiler does the correct thing and the RTCC gets the correct FAST interrupt treatment.

So it would seem that the compiler for whatever mistaken reason has forced SSP2 to be high priority! This is unacceptable... the compiler can never know what the hardware/systems designer intends!

Any suggestions on ways to convince the compiler to force SSP2 interrupt to low priority will be greatly appreciated.

[dyeatman]

Have you informed CCS?

[webbone]

No, due to the fact this an older compiler (I actually use two versions of 3.xxx and one of 4.xxx depending on the project/processor/compiler bugs I have to avoid)... but mainly due to the fact I am not currently under a support contract.

[dyeatman]

You have nothng to lose by askng for a one time download to "fix" the bug in a version you paid good money for

[Ttelmah]

First thing to say, is don't use 'fast'. Use 'high'. Fast, implies that the compiler _will not_ generate code to save the registers, and it becomes your responsibility to poll which interrupt has actually occurred. 'Fast', is equivalent to the low priority 'int_global', and may be what is actually causing the problem.
Second, double check the data sheet, and erratas. When high priority interrupts are enabled, some interrupt automatically go high (INT_EXT), and on some chips, there are erratas, giving errors on particular peripherals, is high_priority is enabled, and they are not assigned to the high priority vector. I have a 'niggling' memory, that the 18F8722, has such an erratum, on some silicon versions, and I suspect CCS is automatically applying the 'fix', and this is what you are seeing.....

Best Wishes

[Guest]

[Ttelmah]

There is a major erratum, with the use of the RETFIE 1 instruction.
The normal 'bodge', is to not use this instruction on these chips, but I'd suspect what CCS are doing, is completely getting rid of the ability to use this, and since the 'FAST' handler, _relies_ on this as they code it, your using this, results in them effectively getting rid of the ability to have two interrupt levels.....

Best Wishes

[webbone]

I am aware of the erratum (#7 for Rev A silicon - fixed in Rev B silicon) -As previously stated (I was on a different computer and forgot to login prior to posting), I have dealt with the issue by patching the low priority interrupt context restore code so as to NOT use the MOVFF instruction.

I have done a little bit more evaluation of different options (both in SPI and I2C flavors) - it turns out that the problem is in the #int SSP2 directive - if you use it at all the compiler does the wrong thing... which means there isn't a workaround for this problem short of writing all of the interrupt handler myself (which is somewhat difficult if not impossible since the context save/restore will need to change depending on what decisions the compiler makes)....GRRR.

UPDATE: Compiler V4.062 DOES generate the correct code - as long as I can guarantee I have Rev B silicon this is workable (assuming no other sticky issues) - this version of the compiler generates code that CANNOT be patched for Rev A silicon unfortunately...