• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 80 subscribers
  • Views 2615 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using the Real Time Clock RTC_A or RTC_B as a general-purpose counter in the MSP430F66xx

Steffen Kristensen
Intellectual 520 points
Other Parts Discussed in Thread: MSP430F6638

Hi,

I’m migrating from MSP430F46xx to the new MSP430F66xx device.

In my MSP430F46xx I have always been using the basic timer but in the MSP430F66xx it’s removed.

Does anybody have a link to some C sample code showing how to use the RTC_A or RTC_B as a general-purpose counter and interrupting at intervals of 64 Hz, 32 Hz, 16 Hz, 8 Hz, 4 Hz, 2 Hz, 1 Hz

 Regards

Steffen kristensen

  • 0
    Expert 1790 points

    Hello Steffen,

    I use RTC_A of 5528 as timer im clock mode. It allows you also in this mode to generate the requested interrupts.  In my example I use 1/128 interrupts.

    Here the code (with bug fix 2010-08-23):

    void Timer::Init(void)
    {
      RTCCTL01 = RTCMODE; // + RTCTEVIE;
      RTCCTL23 = RTCCALF_1; // 512Hz output
      P2DIR |= BIT6;
      P2SEL |= BIT6; 
      RTCPS0CTL = RT0PSIE + RT0IP_7; // 32768/256 = 128 interrupts per sec
    }

      // Name:  __interrupt void RTC(void)
      // Resources used:
      //    RTC interrupt vector
      // Description:
      //    source for the timer events

    #pragma vector=RTC_VECTOR 
    __interrupt void Timer::RTC(void)
    {
      switch(__even_in_range(RTCIV,16))
      {
        case 0: break;                          // No interrupts
        case 2: break;                          // RTCRDYIFG
        case 4: break;                          // RTCEVIFG
        case 6: break;                          // RTCAIFG
        case 8:                                 // RT0PSIFG
          ElapsedTimeCounter++;
          if(PopIndex != PushIndex) //Anything in the queue
            if(NextQueueEvent <= ElapsedTimeCounter)  //Something ready in queue
              goto Wakeup;                 
          if(PauseWakeup) // Pause to wake up
              goto Wakeup;       
          break;
        case 10: break;                         // RT1PSIFG
        case 12: break;                         // Reserved
        case 14: break;                         // Reserved
        case 16: break;                         // Reserved
        default: break;
      }
      return; // No wakeup
    Wakeup:
      __bic_SR_register_on_exit(LPM0_bits); //weak up CPU 
    } 

    I hope this helps.

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Intellectual 520 points

    Hi

    Thanks for the reply and sample code.

    The sample code works fine in a MSP430F66xx, you just need to set the PxSEL bit to get the 1 hz output.

     

    In the MSP430F66xx I would like to use RTC_A as a counter, but in my IAR tool I can’t clear RTCMODE to switch to counter mode.

    In the document "MSP430x5xx/MSP430x6xx Family (SLAU208G)" are 2 chapters, Chapter 16 (RTC_A) and chapter 17 (RTC_B), in RTC_A are described how to switch to counter mode, in RTC_B it’s not possible.

    Both RTC_A and RTC_B share same clock registers from 04A0H so I’m confused about how to set the device to counter mode.

    Maybe it's not possible in a MSP430F66xx?

    Can TI comment on how to set the RTC to counter mode in a MSP430F66xx?

     

    Regards

    Steffen kristensen

     

  • 0 in reply to Steffen Kristensen
    Expert 1790 points

    Hello Steffen,

    Several sources say consistent that RTC_B has no counter capability. The coresponding RTCMODE bit (5) in RTCCTL1 is not avaliable (reserved) on RTC_B.

    MSP430F6638 has an RTC_B only.

    Regards

    Guenther

  • 0 in reply to Guenther Klenner
    Guru 227245 points

    Guenther Klenner said:
    MSP430F6638 has an RTC_B only.


    indeed. The timer/counter capability from the RTC_A module has been stripped-off into a full-featured third TimerA module, including three CCRx blocks.

  • 0 in reply to Jens-Michael Gross
    Intellectual 520 points

    Thanks for all the feedback, I highly appreciate it.

    The MSP430F6638 has an RTC_B only, so no counter capability there.

    I suggest that this information is written into that next revision of the "MSP430x5xx/MSP430x6xx Family (SLAU208G)"  so it’s clear for everybody.

     

    Regards

    Steffen kristensen

  • 0 in reply to Steffen Kristensen
    Guru 227245 points

    Steffen Kristensen said:
    I suggest that this information is written into that next revision of the "MSP430x5xx/MSP430x6xx Family (SLAU208G)"  

    I don't think so.
    I don't really like it, but the general philosophy of TI is to put a description of everything that appears in a member of a family into the family users guide and the actual features of a device into the device datasheet. I had to manipulate Acrobat anyway so I can open the same users guide several times to look at different but internally connected sections (that's the weakest spot of the users guide - the connections between different modules are often not clear). So it makes no problem viewing the datasheet and the users guide side-by-side.

    The 6638 datasheet clearly tells that it has an RTC_B. No mention of an RTC_A.
    Similarly, the 54xx does not have a REF module or a memory mapping module, or an USB, yet all are listed in the family guide. Same situation.

    If the description of a car reads: available with 1.1l motor and optionally with 1.2l motor' it does not mean that there is a version with both motors. Yet there might be one without a motor at all (don't laugh, I once got one offered second-hand and this fact was NOT mentioned in the ad)

    We have a similar problem here. Out devices are assembled of a set of base PCBs. An actual device can have an RF PCB or not, it can have a switching power supply or not, it can have one of several sensor boards or not. There are devices with sensor oard, power supply and RF, or only RF and power supply, possibly feeding several sensor board without own power supply and RF. etc.

    So the question was: do we write separate documentations for each combination (with the requirement to alter most of htem if one of the components inside is altered)?
    It greatly increases update effort and also increases the risk of accidentally skipping an update. Things can grow very opaque for the engineer who has to write the docs.

    Or do we write a 'component descrtiption list' and jsut a small datasheet for eadch assembly? This is more or less what TI does.
    It makes things relatively easy for the doc writer but way more difficult to handle for the customer. Yet it is relatively safe from missing updates.

    We made something in the middle: The component features are compiled into the device datasheet. The datasheet contains tags which pick the required sections from the component descriptions and compiles them into one document. Almost like a code project with includes and conditional compiling. LaTex allows this kind of conditional document construction.
    It is a bit more complicated to initially set-up but greatly decreases updating effort while giving the user a single document covering exactly his device.
    A makefile-like process checks for necessary recompilations by date changes of the sources.

    Anyway, writing a documentation is the least-liked part of any engineering process. And I really hate it. :)

**Attention** This is a public forum