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.

MSP430FR5949 REV F - Comparator Initialisation Issues

Other Parts Discussed in Thread: MSP430FR5949

Hi,

I have a customer who is having issues with the comparator on the MSP430FR5949 (Rev F). The first comparator reading out of reset is always incorrect. Subsequent readings are OK. They did not see this problem with an earlier revision of the silicon. Has anyone seen this before?

As a temporary workaround, they have chosen to discard the first reading.

Regards,

Chee Boon

  • Hi Chee Boon,

    Could you provide more details about your setup and maybe a code snippet or code example that reproduces the issue? Do you see the issue even with the TI code example?

    Are you talking about the ADC12_B window comparator, or the COMP_E module? If it's the COMP_E module, have you also checked to see if the COMP7 erratum applies. www.ti.com/lit/pdf/slaz465

    Regards,

    Katie

  • Hi Katie,

    We use COMP_E module to test a battery voltage by reading the value at P1.0 (C0) and comparing it to the internal 1.2V reference voltage. when the battery is full, our circuit setup provides 1.56V to the comparator input P1.0.

    As described by Chee Boon, what we find is that the first read of the comparator after a Reset state gives us an incorrect result as if the battery is below the ref voltage. all Subsequent readings give correct results until the MCU is reset again.

    This issue appeared first on the Rev F silicon, we didn't see it with previous revisions when we used exactly the same code.

    this is a snippet of the code where we use the COMP_E:

    //------------------------------------------------------------------------------
    //

     unsigned char GetBatteryStatus(void)

    {

        unsigned char status = BATTERY_UNKNOWN;

         P1REN &= ~(BIT0 + BIT1);

        P1DIR &= ~(BIT0 + BIT1);

        P3REN &= ~BIT6;

        P3DIR |= BIT6;

        P3OUT &= ~BIT6;

     

        // Setup Comparator_E

        CECTL0 = CEIPEN | CEIPSEL_0;                                // Enable V+, input channel CE0

        CECTL1 = CEPWRMD_0;                                            // normal power mode

        CECTL2 = CEREFL_1 | CERS_3 | CERSEL;              // VREF is applied to -terminal

                                                                                             // R-ladder off; bandgap ref voltage

                                                                                             // supplied to ref amplifier to get Vcref=1.2V

        CECTL3 = BIT0;                                                          // Input Buffer Disable @P1.0/CE0

        CECTL1 |= CEON;                                                      // Turn On Comparator_E

     

        __delay_cycles(2400);                                                // delay 150us for the reference to settle

     

        if(CEOUT & CECTL1)

        {

            status = BATTERY_OK;

        }

        else

        {

            status = BATTERY_FAIL;

        }

     

        CECTL1 &= ~CEON;

     

        P3REN |= BIT6;

        P3OUT |= BIT6;

        P1DIR |= (BIT0 + BIT1);

        P1REN |= (BIT0 + BIT1);

        P1OUT |= (BIT0 + BIT1);

     

        return status;

    }

    //------------------------------------------------------------------------------

    Thanks,

    Saar

  • Hi Saar,

    I am wondering if this could be some sort of timing related issue. If you add a pin-toggle to your code immediately before you read the CEOUT bit, you could use a scope to monitor the line for the pin toggle and monitor the input to the Comp_e to determine exactly what voltage it was at right before the CEOUT bit was being read - then you'd be able to see if it had crossed the threshold for the reference yet for sure.

    Another test would be to add some additional delay before reading CEOUT and see if at some amount of delay the issue disappears. This kind of information could be important for you to debug your issue.

    Regards,

    Katie

**Attention** This is a public forum