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.

MSP-EXP430FR2433: MSP430FR2433 SMCLK related issues confirmed.

Part Number: MSP-EXP430FR2433

Hello, please check the attached code. We have configured CS, captrue timer, and ADC functions, but we found that the following configuration in adc_init will affect the accuracy of SMCLK.
TA1CTL = TASSEL__SMCLK | MC__UP | TACLR;
We tested the mg_sleep interface and flipped the P1.0 pin every 1S, but when the adc_init interface was called, the pin level was not changed according to the 1S time.but when adc_init interface is shielded, and the 1s time was normal.(Oscilloscope test P1.0)
We currently need to use the ADC function simultaneously in the current project, so please help confirm.
Please see the attachment for the project code. thanks.

8054.PUMA-MCU-test.zip

  • As you say "but when the adc_init interface was called, the pin level was not changed according to the 1S time". Do you mean the pin will not change or the change time is longer than 1s.

  • In the actual test situation, when the adc_init interface is called, the change time exceeds 1S, which is about 1.6s.

  • I think it is disturbed by the interrupt. I advise you use a timer to generate a 1s clock

  • We have tried to annotate the adc_init interface, the mg_sleep time is normal, and the adc_init interface is turned on, the time is abnormal.
    At the same time, we tried to modify the following configuration in the adc_init interface:
    change
    TA1CTL = TASSEL__SMCLK | MC__UP | TACLR;
    to
    TA1CTL = TASSEL__ACLK | MC__UP | TACLR;
    The mg_sleep 1s time returns to normal, so "TA1CTL = TASSEL__SMCLK | MC__UP | TACLR;" will affect the SMCLK clock?

  • As I tried, the reason is that you put too much code in the Timer interrupt. That cause a delay.

    After I remove all the code in the timer interrupt. It goes to 1s.

  • As Eason says, __delay_cycles is a simple spin loop, and doesn't take into account any background (interrupt) activity. In your case, that activity includes 80000 calls to ADC_ISR (and maybe some calls to TIMER0_A1_ISR). That adds up.

    You're already using both timers, but consider that ADC_ISR is called at the same rate as the TA1 overflow (80kHz). if you count 80 of those, you get 1 millisecond. E.g.

    if (++tick_count >= 80) {
        tick_count=0; 
        ++ms_clock;
    }

    would give you a simple software clock that you can use to delay for some number of milliseconds. A delay might look something like:

    void ms_delay (unsigned ms) {
        unsigned start = ms_clock;
        while ((ms_clock - start) < ms) /*EMPTY*/;
        return;
    }