How is this PIC32 ISR tied to the Timer1 interrupt?

[Osirus]

Hi, new poster here.

I'm learning to use the PIC32 with the assistance of a textbook, datasheets, and anything else I can get my hands on. I'm trying to do as much as possible directly with registers instead of peripheral libs, etc.

I needed an interrupt every 1/60 of a second, and I got it working with Timer1 following some instructions, however I don't understand why it works. What actually assigns the Timer1 interrupt to this particular ISR?

The ISR function:

Code: [Select]

#pragma interrupt InterruptHandler ipl1 vector 0
void InterruptHandler(void)
{
    // Do stuff...
   
    IFS0bits.T1IF = 0;
}
And the Timer1 config:

Code: [Select]

    T1CON = 0x8010; //Timer1 ON, Prescaler 8
    PR1 = GetPeripheralClock() / 60;

    __asm__("EI");
   
    IFS0bits.T1IF = 0; // Timer1 Interrupt Flag cleared
    IPC1bits.T1IP = 1; // Timer1 Interrupt Priority 1
    IEC0bits.T1IE = 1; // Timer1 Interrupt Enable
Aside from the priority level matching, I don't see what it is that defines this ISR for Timer1.

[mikeselectricstuff]

You haven't put it into multi-vector mode, so any interrupt will call your code, you just only happen to have one source enabled, so it works.
Until you enable another interrupt source.

[Osirus]

You haven't put it into multi-vector mode, so any interrupt will call your code, you just only happen to have one source enabled, so it works.
Until you enable another interrupt source.

I see. Thanks, that's kinda what I thought, that it was just a ISR for everything.

[mikeselectricstuff]

BTW you should use IFSxCLR = <mask> to clear int flags, as the compiler does not compile <flag=0> into an atomic operation, so if you have multiple things accessing flags in the same register (Especially a mix of foreground & background tasks) you can get some horrifically hard to debug "fails once in a blue moon" type situations.

[andersm]

Code: [Select]

#pragma interrupt InterruptHandler ipl1 vector 0
void InterruptHandler(void)
{
}

This format for decorating ISRs is deprecated. The current way is to use a function attribute, or the convenience macros in sys/attribs.h. See chapter 14 of the XC32 manual for full details.

[newbrain]

Code: [Select]

#pragma interrupt InterruptHandler ipl1 vector 0
void InterruptHandler(void)
{
}

This format for decorating ISRs is deprecated. The current way is to use a function attribute, or the convenience macros in sys/attribs.h. See chapter 14 of the XC32 manual for full details.

This is one of the reasons I like Cortex-M a lot  : ISRs are just regular C functions, no magic spells outside standard C for the user and the compiler, even if hidden  in a #pragma or a convenience macro.

[jaromir]

EEVblog forum rule 27:
In every PIC thread, somebody must explain how much better is some other MCU.

[newbrain]

EEVblog forum rule 27:
In every PIC thread, somebody must explain how much better is some other MCU.

I was not PICking specifically on MIPS, : the last I programmed on a MIPS was with this, "some" time ago.
More like something I noticed with most other archs I dealt with, and totally a personal opinion.

[Luminax]

Just a clarification, is that a code generated by the likes of Harmony and/or MPLab Code Configurator? because it seems a lot like it.

In the event that it does, there's an ISR handler routine that passes any matching interrupt to its matching ISR to be passed to their own specific callbacks somewhere inside the generated codes

[jesuscf]

BTW you should use IFSxCLR = <mask> to clear int flags, as the compiler does not compile <flag=0> into an atomic operation, so if you have multiple things accessing flags in the same register (Especially a mix of foreground & background tasks) you can get some horrifically hard to debug "fails once in a blue moon" type situations.

Here is a portion of the output "xc32-objdump -D -S TimerIRQ.o" for a piece of code similar to OP's code.

Code: [Select]

IFS0bits.T1IF=0; // Clear timer 1 interrupt flag
  54: 3c020000 lui v0,0x0
  58: 8c430000 lw v1,0(v0)
  5c: 7c032104 ins v1,zero,0x4,0x1
  60: ac430000 sw v1,0(v0)
Can anybody fluent in MIPS assembly explain what is going on?  Why isn't the assignment atomic?  Thanks in advance.

[Luminax]

Probably due to the fact that TMR register's upper 8-bit can't be directly written?

A write to the high byte of Timer1 must also take place
through the TMR1H Buffer register. The Timer1 high
byte is updated with the contents of TMR1H when a
write occurs to TMR1L. This allows a user to write all
16 bits to both the high and low bytes of Timer1 at once.
The high byte of Timer1 is not directly readable or
writable in this mode. All reads and writes must take
place through the Timer1 High Byte Buffer register.
Writes to TMR1H do not clear the Timer1 prescaler.
The prescaler is only cleared on writes to TMR1L.

[andersm]

Code: [Select]

IFS0bits.T1IF=0; // Clear timer 1 interrupt flag
  54: 3c020000 lui v0,0x0 # Load upper 16 bits of IFS0 address
  58: 8c430000 lw v1,0(v0) # Load IFS0 to CPU register
  5c: 7c032104 ins v1,zero,0x4,0x1 # Clear bit
  60: ac430000 sw v1,0(v0) # Store CPU register to IFS0
Can anybody fluent in MIPS assembly explain what is going on?  Why isn't the assignment atomic?  Thanks in advance.

MIPS is a load-store architecture. The PIC32 has extra hardware registers for atomic bit set/clear/invert, but the compiler doesn't automatically transform accesses of one register to a different one.

[mikeselectricstuff]

Code: [Select]

IFS0bits.T1IF=0; // Clear timer 1 interrupt flag
  54: 3c020000 lui v0,0x0 # Load upper 16 bits of IFS0 address
  58: 8c430000 lw v1,0(v0) # Load IFS0 to CPU register
  5c: 7c032104 ins v1,zero,0x4,0x1 # Clear bit
  60: ac430000 sw v1,0(v0) # Store CPU register to IFS0
Can anybody fluent in MIPS assembly explain what is going on?  Why isn't the assignment atomic?  Thanks in advance.

MIPS is a load-store architecture. The PIC32 has extra hardware registers for atomic bit set/clear/invert, but the compiler doesn't automatically transform accesses of one register to a different one.

There is no reason it couldn't though. I'd go as far as to say they shouldn't even define the bits in the header file, or at least make them read-only.

[andersm]

There is no reason it couldn't though.

No, but there's also no reason it should. It would be surprising if the compiler generated an access to a different address than what you specified.

I'd go as far as to say they shouldn't even define the bits in the header file, or at least make them read-only.

Using C bit fields to alias hardware registers has never been a good idea.

[mikeselectricstuff]

There is no reason it couldn't though.

No, but there's also no reason it should.

Yes there is - optimisation.
It's the sort of thing that can easily be done as a peephole optimisation in the device-specific code generator

[jesuscf]

I'd go as far as to say they shouldn't even define the bits in the header file, or at least make them read-only.

100% agree.  Anyhow, I changed the line in my code:

IFS0bits.T1IF=0; // Clear timer 1 interrupt flag

to:

IFS0CLR=0x00000010; // Clear timer 1 interrupt flag, bit 4 of IFS0

Thanks again everybody, specially Mike for pointing this out.  I think this is really important because every example I found on the internet uses IFS0xbits to clear the interrupt flag.  On the other hand the PIC32MX Family Reference Manual examples always use IFSxCLR.

By the way, Example 14-9 in the user manual (http://ww1.microchip.com/downloads/en/DeviceDoc/61132B.pdf) has a copy/paste typo

Code: [Select]

/*
The following code example demonstrates a simple interrupt service routine for Timer
interrupts. The user’s code at this ISR handler should perform any application
specific operations and must clear the corresponding Timer interrupt status flag
before exiting.
*/
void __ISR(_Timer_1_Vector,ipl3)Timer1Handler(void)
{
    ... perform application specific operations in response to the interrupt
    IFS0CLR = 0x00000010; // Be sure to clear the Timer 2 interrupt status
}

[mikeselectricstuff]

IFS0CLR=0x00000010; // Clear timer 1 interrupt flag, bit 4 of IFS0

The mask is defined in the header file :
IFS0CLR=_IFS0_T1IF_MASK;

[andersm]

Yes there is - optimisation.
It's the sort of thing that can easily be done as a peephole optimisation in the device-specific code generator

It would only work with single-bit registers, and having them work differently from others would be insane.