SparkFun Forums

[Mike2Forums]

Hello Forum members,

I am using MSP430F2618 with a XTAL of 1MHz connected to XT1 pins. The bus clock
(MCLK) is 250KHz while the aux clock (ACLK) is 1MHz. I am using ACLK to
different peripherals like UART, SPI, timer etc.

Is it possible that the timer execution will get affected as the MCLK and ACLK
differ very much - i.e. ACLK = four times MCLK? MCLK will be used to execute the
instructions while ACLK will drive the peripheral.

I observed similar while working with the timer ISRs. I am using
TI-MSP430FET(PIF) to debug my code having a timer ISR and updating the TBCCR0
and TBCCR1 registers. I observed a little difference in two register values when
I put breakpoint in ISR. Is the debugger playing any role for timer execution?

I have read the datasheet where it is stated that some cpu cycles will be used
to enter and exit the timer ISR. How is this affecting the timer counts?

Anyone having similar issues/observations.........?? Thanks in advance.

Mike

[theatrus]

The debugger is non-deterministic when it stops the CPU. If you want to check the timing, I'd suggest toggling a GPIO line in the ISR.

250kHz is pretty slow. Any particular reason for this speed? Its often better to do more work quicker and sleep longer. I like running with an MCLK of around 4MHz on low power stuff (8MHz for the 54xx).

[Mike2Forums]

Hello theatrus,

My requirement is to keep controller awake at all the times but at the same time keep the current consumption of it to low value @ 500uA. Hence the MCLK=250KHz.

I tried using GPIO to observe the firmware behaviour, it is ok. But for timer counts in TBR, CCR0 and CCR1, I observed the difference when I put break points.

Mike

[theatrus]

Breakpoints, in my experience on the MSP430F1611, do not stop the timers at a deterministic point. I haven't found a good workaround for this, except to not rely on time sensitive breakpoints.

[Mike2Forums]

I observed the difference when I put break points - by this statement I mean this difference in counts is reflected in code execution also, not at the time of breakpoints only. At run time also this difference is there which is causing my further calculations to behave incorrectly.

[gm]

It is possible that you are missing interrupts. If your ISR is long and/or your rate of interruptions is high, the ISR may not be finishing before the next interrupt fires.

I would suggest cranking up MCLK to see if this cures the problem. If you are running MCLK slow to cut current consumption remember that the current consumption is quite linear with regard to MCLK frequency. Thus, running it fast and short is the same as slow and long, power-wise.

[Mike2Forums]

Hello gm,

I will try to bring MCLK and ACLK on the same platform and will chk. But does TI specifies any limitation on usage of MCLK and ACLK or SMCLK? Do they need to run on a same frequency level? I checked with MSP430 datasheet but could not find any thing similar.

Increasing MCLK which is bus clock in other words, is a concern for passing the EMI/EMC tests as per feedback from my hardware colleagues.

Anyway, thanks for your help.

Mike.

[gm]

I was looking through the datasheet and I noticed on page 56 that the maximum input frequency for the USCI in UART and SPI mode is the system clock (Fsystem) so it sounds like you shouldn't run the peripherals faster than MCLK.

[Mike2Forums]

Though it is mentioned for USCI, does it apply for timer as well?

Because if I use same MCLK and ACLK and configure timer in UP mode, the PWM generation works fine for all the duty cycle values. The limitation of UP mode is the max count for timer will be the PWM period and I need timeouts of more values which has posed timer configuration in Continuous mode.

Mike.

[gm]

The user guide states the following:

Note: Modifying Timer_A Registers
It is recommended to stop the timer before modifying its operation (with
exception of the interrupt enable, interrupt flag, and TACLR) to avoid errant
operating conditions.
When the timer clock is asynchronous to the CPU clock, any read from TAR
should occur while the timer is not operating or the results may be
unpredictable. Alternatively, the timer may be read multiple times while
operating, and a majority vote taken in software to determine the correct
reading. Any write to TAR will take effect immediately.

The emphasis is mine because in your case the two clocks are asynchronous in relation to each other.

[Mike2Forums]

But then this is a big restriction on using higher ACLK thank MCLK? Does this could happen to any other peripheral using higher ACLK than MCLK?

Mike.

[gm]

I can't answer that as I do not know. The vast majority of applications have MCLK >> ACLK. You are getting into territory that is not very well explored and so I think you need to talk to a TI FAE at this point to get your questions answered.

[theatrus]

Increasing MCLK which is bus clock in other words, is a concern for passing the EMI/EMC tests as per feedback from my hardware colleagues.

Unless you somehow bus MCLK around the board for 100 feet, the on-chip frequency isn't going to impact anything. There should be no issues whatsoever with any normal clock speeds on the MSP430 from my experience (I run at 4-8MHz).