Compiler instruction needed to set the SR at an interrupt routine.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Compiler instruction needed to set the SR at an interrupt routine.

2,518 Views
Marcel
Contributor II

Hi,

 

We are using MCF51QE128 and MCF51JM128 devices with CWDS for Microcontroller 6.2, build 8127.

 

How can I instruct the compiler to set the Status Register to 0x2700 at an interrupt routine in order to disable all higher priority interrupts. I tried using "__declspec(interrupt:0x2700) void my_handler(void)" as explained in the help file, but the compiler generates the error message "identifier expected" and does not seem to recognize the interrupt keyword.

 

Manually inserting assembly (at the beginning of the interrupt function to set the status register) does not work, because the epilogue instructions are inserted before the assembly and the processor will have sampled for interrupt requests already. Also I do not want to set the CPUCR[IME] bit.

 

Thanks,

Marcel

Labels (1)
0 Kudos
11 Replies

898 Views
CrasyCat
Specialist III

Hello

 

Did you try using macro DisableInterrupts?

 

There are 2 macros EnableInterrupts and DisableInterrupts, which can be used to enable or disable interrupts.

These macros are defined in hidef.h.

 

So just make sure you include that file in your source file.

 

CrasyCat

0 Kudos

898 Views
Marcel
Contributor II

I know these macros exist, but they don't work either, because the compilers always inserts the prologue code before the first statement. See the example below. What I need, is to disable interrupts as the first instruction (STLDSR) in the interrupt service routine. This makes sure no other higher interrupt request can interrupt my isr.

 

See the text on page 124 of the MCF51JM128RM.pdf  manual (6.3.2 - exception processing overview).

 

;  221: __interrupt void my_isr(void)
;  222: {
;
0x000082BA                    _my_isr:
;                             my_isr:
0x000082BA  0x4FEFFFF4               lea      -12(a7),a7
0x000082BE  0x48D70103               movem.l  d0-d1/a0,(a7)
;
;  223:     DisableInterrupts
;  224:         
;
0x000082C2  0x40C0                   move     sr,d0
0x000082C4  0x008000000700           ori.l    #0x700,d0             ; '....'
0x000082CA  0x46C0                   move     d0,sr

0 Kudos

898 Views
CompilerGuru
NXP Employee
NXP Employee

With CW 10.0 beta (I don't have 6.2) I saw that the compiler is using STLDSR with a #pragma TRAP_PROC (and note that this is different than its behavior with __interrupt). Not sure why the two ways of defining an interrupt method are behaving differently (or how to specify another mask than to mask out all interrupts). I would suggest a service request to get a better answer.

(Note: I did never work on the CF compiler, so I really don't know any details.)

 

0 Kudos

898 Views
CrasyCat
Specialist III

Hello

 

Sorry I missed the point that you needed that to happen in interrupt function entry code.

 

I did run some tests on CodeWarrior MCU V6.2.

 

If you define you interrupt in one of the following way you get the strldsr  #0x2700 instruction in interrupt entry code:

 

#pragma interrupt on
void my_isr(void) {

 count++;
}

#pragma interrupt off

 

or

 

#pragma TRAP_PROC
void my_isr(void) {

 count++;
}

CrasyCat

0 Kudos

898 Views
Marcel
Contributor II

Thanks for the suggestions.

 

Both methods of defining an interrupt function this way, do indeed generate the STLDRS instruction, but also seem to use vector_0 as the interrupt vector number. This conflicts with the vector_0 definition needed for INITSP and the linker thus generates an error.

 

I would be happy to use the #pragma interrupt or #pragma TRAP_PROC, if I could manually bind the interrupt handler to an interrupt vector. Another thing to consider is that our vector table is redirected to RAM. That is also the reason we are using the __interrupt keyword right now without a specific vector number. The compiler/linker ignores the vector redirection.

0 Kudos

898 Views
Marcel
Contributor II

I don't know if my previous post was clear to you, but my question regarding the use of #pragma interrupt or #pragma TRAP_PROC is, if it is possible to disable or override the interrupt vector number. As stated earlier, our vector table is redirected to RAM. So this should be considered also.

0 Kudos

898 Views
CrasyCat
Specialist III

Hello

 

How are you specifying the vector number then?

The code snippet you provided

     __interrupt void my_isr(void) {

    ...

    }

does not initialize any vector number as far as I can tell.

 

Where and how did you specify the interrupt vector number?

 

CrasyCat

0 Kudos

898 Views
Marcel
Contributor II

Hello

 

>> Another thing to consider is that our vector table is redirected to RAM. That is also the reason we are using the __interrupt keyword right now without a specific vector number. The compiler/linker ignores the vector redirection.

 

We specify the interrupt vector for the interrupt handler using a separate vector table (origally derived from exceptions.c). The linker command file is modified to have the vector table point to RAM at run-time.

0 Kudos

898 Views
Marcel
Contributor II

The compiler is not in line with the help file.  Why does the compiler not understand "__declspec(interrupt:0x2700) void my_handler(void)" as mentioned in the help file? I consider this a bug! Other pragmas are not helping either!

 

FYI: When I enable the compiler option "ANSI Keywords only" the compilation of the file succeeds without error. But generates numerous errors for other files, CodeWarrior files (e.g. startcf.h) included.

0 Kudos

898 Views
CrasyCat
Specialist III

Hello

 

I would recommend you to submit a service request for that.

Click here to submit a service request.

Make sure to attach a reproducible project and installed product information to the service request.
To generate the required information:
- Start CodeWarrior
- Open the project
- Select "Help" -> "Pack and Go" and follow instructions on the screen.

Attach the generated .zip file to the SR.

 

CrasyCat

0 Kudos

898 Views
Marcel
Contributor II

Thanks CrasyCat,

I will do that.

 

Marcel

0 Kudos