MSP430FR5994: RTC interrupt vector priority

MICHAEL MACLEAN

Part Number: MSP430FR5994

hi all,

i am using the RTC and having a problem understanding the priority of the RTCIV. My code sends the time to a display, but it is one minute slow. i have traced this to be the event interrupt (every minute, that sends the time), is being executed before the ready interrupt (on RTCRDY, that updates the time). I was expecting that RTCRDYIFG was higher priority than RTCEVIFG, and on a minute rollover they will both be set (per fig 29-1 in user manual).

#pragma vector = RTC_VECTOR
__interrupt void RTC_ISR(void)
{
    switch(__even_in_range(RTCIV, 16))
    {
    case RTCIV_NONE: break;                 //No interrupts
    case RTCIV__RTCOFIFG: break;            //RTCOFIFG - fault.
    case RTCIV__RTCRDYIFG:                  //RTCRDYIFG - triggered just after 1Hz reg-update.
        //Safest point to Update the RTC internal time
        sRtcTime.Seconds = HWREG8(RTC_C_BASE + OFS_RTCTIM0_L);
        sRtcTime.Minutes = HWREG8(RTC_C_BASE + OFS_RTCTIM0_H);
        sRtcTime.Hours = HWREG8(RTC_C_BASE + OFS_RTCTIM1_L);
        sRtcTime.DayOfWeek = HWREG8(RTC_C_BASE + OFS_RTCTIM1_H);
        sRtcTime.DayOfMonth = HWREG8(RTC_C_BASE + OFS_RTCDATE_L);
        sRtcTime.Month = HWREG8(RTC_C_BASE + OFS_RTCDATE_H);
        sRtcTime.Year = HWREG16(RTC_C_BASE + OFS_RTCYEAR);
        Task_SysTick_1s.flag = true;
        APP_WAKEUP;
        break;
    case RTCIV__RTCTEVIFG:                  //RTCEVIFG - Interrupts every minute
        Task_MinuteTick.flag = true;
        APP_WAKEUP;
        break;
        break;
    case RTCIV__RTCAIFG: break;
    case RTCIV__RT0PSIFG: break;
    case RTCIV__RT1PSIFG: break;
    default: break;
    }
}

in the main loop it checks, checks if Task_MinuteTick is set and copies out sRtcTime (Calendar) to another instance and sends it on. I can see with gpio toggles in each case above that EVIFG runs 3.9-4ms before RTCRDY, but i though it would be the other way round?

i have a workaround for it, but just want to know if im misinterpreting how the interrupt vector is working.

thanks,

michael.

over 4 years ago

0 Bruce McKenney over 4 years ago

Guru 100705 points

I think the key to this is in User Guide (SLAU367P) Sec 29.2.5. RTCRDY isn't really a one-second trigger, though it happens every 1 second. It triggers on the RTCRDY rising edge (128/32768)=~4ms after the one-second transition, once the CPU and RTC clocks have sync-ed. Strictly speaking, you probably shouldn't (and you don't) read the RTC registers during the RTCEVIFG trigger, since I expect RTCRDY=0 then.

0 MICHAEL MACLEAN over 4 years ago in reply to Bruce McKenney

Intellectual 575 points

Ah of course, thank you! That makes sense, yep i was aware about the keep out window so only read the time on rtcrdy, but just never clicked that it would mean the event irq would go first, i was staring right at it as well in fig 29-1. I was too focused on the user guide saying that RTCRDY is higher priority than RTCEV, which in practise is not the case.

I'm happy the workaround is ok then. the problem was:

RTC rolls over from say 10:10:59 to 10:11:00.
1Hz output (RT1PS Q6) goes through the 3.9ms delay block before setting the RDY interrupt
in meantime, the minute event interrupt RTCEV is triggered, it gets round the main loop and safely copies out the time (10:10:59 from the safe copy sRtcTime, disables irq while copying it) for the user interface, before 3.9ms elapses.
Then after 3.9ms, the time sRtcTime is updated to 10:11:00, but its too late by that point. so the UI display is always a minute slow
Workaround was to just set a static flag in the RTCEV minute interrupt, then check/clear the flag in the RTCRDY interrupt, to set Task_MinuteTick.flag only after the time has been updated.

Cheers.

**Attention** This is a public forum

MSP low-power microcontrollers

MSP low-power microcontroller forum

MSP430FR5994: RTC interrupt vector priority