• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 78 subscribers
  • Views 363 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Timer A and B are erratically synchronous

Jürgen Wissenwasser
Intellectual 490 points
Other Parts Discussed in Thread: MSP430F5438A

I started a project where I need both timers for a PWM (high-side and low-side) where a slight delay shall avoid shoot-through in an output stage.

Programming the timer is no problem, but when I try to start them with a certain delay they always (!) become synchronous with their timer-values, i.e. they do not even start independently.

It also seems that they react on the point where I have my breakpoint set before the counter start takes place.

MC-Model: MSP430F5438A, RTC-quartz, DCO=12MHz with XT1 as reference clock, SMCLK=DCOCLK

Config at Initialization:

        mov     #0x0200,&TA1CTL  // SMCLK
        mov     #0x0000,&TA1CCTL1   // keep on output-mode LOW.
        mov     #0x0200,&TB0CTL  // SMCLK
        mov     #0x0000,&TB0CCTL1   // keep on output-mode LOW.

 

Code at start:

        mov     #0x0060,&TA1CCTL1   // set/reset
        mov     #0x0060,&TB0CCTL1   // set/reset
        bis     #0x14,&TB0CTL

        // Here a delay of 14 MCLK cycles is introduced
        bis     #0x14,&TA1CTL

 

It does not matter how many delays I introduce, startup always occurs synchronous,

 

 

Update 2017-Aug-04: Even though the problem was solved a few years ago I'd like to give a hint to other users: Check if your debugger stops timer execution in step-wise debugging. Also, do not set breakpoints directly following the timing-critical commands. I think that additional timing irritations can occure when by the debugger reads data back.

  • 0
    Guru 227245 points

    I never heard of this, and I don’t believe it either.
    So how do you know? How do you read/check the counter values?
    You seem to use up mode. However, you don’t set the cycle time on CCR0.

    You also don’t set a trigger value for CCR1 (between 0 and CCR0). SO how can you get an PWM signal at all?

    I rather guess what you’re seeing is the CPU going into a continuous reset cycle, during which it switches the port pine between high impedance and the initial low state.
    But without any information beyond the two snippets, I can’t really tell anything.
    Sometimes, less is more, but way more often, less is less. :)

**Attention** This is a public forum