ISR priority problem on MCF5213 (C.W. 6.3)

[SoftWareSmolf]

I have an application where I need especially one ISR to have priority. I need to emulate a codec (TDM) interface using the QSPI. From irqdetect to execution of code, minimum of time is reqiured, so this ISR have the highest priority. Due to H.W. interface I must trig QSPI from GPT ch3 irq handler.

Using a scope I can see GPT3 pin toggle (H.W. func), but time from edge to start of SPI data clk can take arbitray amount of time, but is normally fixed and short. From inspecting list file (see below) I can see IRQ level i forced to 7 as the first instruct in this (and in all other) ISR, WHY ????

This means if another ISR with a lower priority is executed right before GPT ch3 triggers, irq is locked and GPT irq will not service until end of first ISR. This explains why my time from pin toggle to QSPI data clk is delayed (GPT ch3 toggle is done by hw counter match, no SW latency)

From what I know 'strldsr' is used in a common ISR for multilevel interrupts....????

list dump:

 __interrupt__ void irqGPT_CH3_Handler ( void ) 
0x00000000                    _irqGPT_CH3_Handler:
;                                         irqGPT_CH3_Handler:
0x00000000  0x40E746FC2700           strldsr  #0x2700
0x00000006  0x4E560000                    link     a6,#0
0x0000000A  0x4FEFFFE8                  lea      -24(a7),a7
0x0000000E  0x48EF03070004           movem.l  d0-d2/a0-a1,4(a7)
;
;  560:   MCF_GPT_GPTC3 += LRCLK_TIME;                                                 // Reload timer for next event
;
0x00000014  0x41F900000000            lea      ___IPSBAR,a0
0x0000001A  0x2248                            movea.l  a0,a1
0x0000001C  0xD3FC001A0016          adda.l   #1703958,a1

In the stationary for the 5213EVB, functions are provided for changing irq level, but they will have no effect unless level is hard coded into each ISR instead of reading current level from SR, save info on stack and modify SR.

Is there som setting in C.W. to change this behaivour or. . . . .

In C.W. help there is very little help to get on ISR...In fact, in general help in C.W. may just as well be omitted, it sucks

Best regards

LAF

[CompilerGuru]

out of Release_Notes\CW_ColdFire_Compiler_Notes.txt
the syntax to specify the interrupt priority is
__declspec(interrupt [ : hexvalue ])
I guess the default is level 7 to make simple code robust.

Daniel

[SoftWareSmolf]

Thanks for your reply Daniel -close but no cigar I think.

I have looked through all my ISR and I have tried to generate a new test project using 'CFInit', every time I compile my code, all ISR have "strldsr  #0x2700" as the first instruction.

This instruction shortcirquits all automatics in the processor for IRQ handeling by forcing the level to 7.

This means no interrups with higher priority can gain access and interrupt low priority, meaning lower priority interrups block execution as they raise the level to 7.

If this first instruction was omitted, evrything would work just fine, but by default messing with the current level, the compiler suspends all automatic re. handeling irq's on hardware level...This, I hope, got to be a mistake.

Currently it means all stationarys that comes with EVB, all code generated be automatic tools e.g. CFInit will not work as expected....

From what I see CodeWarrior 6.3 has a (huge) problem ....

Best regards

LAF

[Napoletano]

I have had the same problem.

As compilerguru has written, __declspec is the solution.

don't declare your ISR with __interupt__.
use __declspec(interrupt[0x2400])void irqGPT_CH3_Handler ( void )

and the first assember instruction will set the SR to 0x2400 and not to 0x2700.

it's not a bug it is a feature :smileyhappy:

daniel

[SoftWareSmolf]

I can not in any of my release notes, find anything re. __declpesc..,  In metroverks.h __interrupt__ is defined that's all.

When I try to add e.g. '__declspec(interrupt[0x2400]) void irqUart1_Handler (void)', I get a compiler error.!!!

Error   : ')' expected
io_handler.c line 495   __declspec(interrupt[0x2400]) void irqUart1_Handler (void)  

Error   : declaration syntax error

Any ideas ????

Best regards

LAF

[Napoletano]

I'm sorry my mistake.

__declspec(interrupt:0x2500) void ComUartISR( void ) is working.

attached the release note if you don't have the same, you don't have CW 6.3

Daniel

[SoftWareSmolf]

Hi Daniel

Thank's for your help, now I can compile..

However, I will still claim this problem to be a major mistake, as SR pushed to the stack by exception processing sequence. This means that you can get current level from reading the SR. I you want navigate relative to current level, 'strldsr' command interfers.

From programmers reference manual this command is intended for a common MULTILEVEL isr (OS-function). In that case I can see some sense in this command, but this can be inserted by inline asm. code.

By the way C.W. is handeling isr, you have to state the level durring setup AND when declare AND you MUST set to same level. This is wery bad for maintaining code and makes it difficult to make re-entry into isr. Further more as I see it, there are no reason what so ever for messing with SR, by default, when entering isr. If one whishes to do so, use inline asm.

I still think this is a major mistake by codewarrior to use this command (by default) upon entering isr. This command is never (in embedded systems and I bet in major systems) nedded. It makes re-use of code messy by contaminating the code with C.W. specific statements and adds unvanted code to isr.

If this 'feature' (read bug) was needed, why not make a radio button in the IDE where to set an option for a common isr....

Claiming having to use '__declspec' for define a simple isr to be a feature says everything about why many people think of C.W. to be a difficult or not easy to use system.

Now, I have been using the C.W. for many years for HC08, HC11, HC12 but especially HC16. The same pattern, what normmaly would be seen as unwanted functionallity, bad behaviour and even bugs is poorly documentated and even somtimes claimed to be a feature....

I have seen so many bugs and errors in especially the stationary for MCF5213EVB that I don't think this code or settings have ever been tested propperly especially not the LCF-files. I have seen wierd things happen in the IDE where readouts of e.g. processor registers was blank, but when right click visible as data...

My impression of C.W. currently is that I am very tempted to scrap all C.W. and black list all C.W. products as low quality (well also low cost, but still) 

Well anyway -thanks for your assistance and I hope C.W. will improve in the future..

Best regards

[CompilerGuru]

Just as note
__declspec(interrupt:0)
does actually cause that the strldsr/move.w #,SR is not generated.

Daniel