• State Resolved
  • Locked Locked
  • Replies 10 replies
  • Subscribers 79 subscribers
  • Views 2548 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.

SVM threshold

Carloalberto Torghele
Intellectual 835 points
Other Parts Discussed in Thread: MSP430F5510

Hi.

I'm working on MSP430F5510 (48 pin).

I'd like to use the SVM high side in order to trigger an interrupt when the battery voltage falls below a certain threshold. I do not need SVS (high and low) nor SVM low side so i disabled them.

Everything works ok except for the fact that if i vary SVSHRVL, the voltage threshold remains the same.

That's my code:

PMMCTL0_H = PMMPW_H;                // PMM Password (enable write)
SVSMHCTL &= ~SVSHE;                 // Disable High side SVS

SVSMHCTL |= SVSHRVL_3;                    // if i vary SVSHRVL_X, the voltage threshold remains the same
SVSMLCTL &= ~(SVMLE+SVSLE);         // Disable Low side SVS/SVM
PMMIFG &= ~SVMHIFG;
PMMRIE = SVMHIE;                     // SVM high-side interrupt enabled.
PMMCTL0_H = 0x00;                      // Wrong PMM Password (disable write)

 #pragma vector=SYSNMI_VECTOR
__interrupt void SYSNMI_ISR(void)
{
    switch(__even_in_range(SYSSNIV,0x12))
    {
        case SYSSNIV_SVMLIFG:
            __no_operation();
            break;
        case SYSSNIV_SVMHIFG:
            __no_operation();
            PMMCTL0_H = PMMPW_H;
            PMMIFG &= ~SVMHIFG;
            PMMRIE = SVMHIE;
            PMMCTL0_H = 0;
            break;
        default:
            __no_operation();
            break;
    }
}

 

What's the problem?


Thanks!

Regards,

Carloalberto

  • 0
    Guru 227245 points

    I'm not sure whether it is a good idea to disable the low side, as it is required when entering LPM or changing frequency (or the MSP might become unstable). However, this does not apply here.

    But more important: the SVSHRVL settings are (as the name indicatres) for teh SVS and not the SVM. Only the SVSMHRRL bit control the SVM.

    I didn't notice myself at first, but then I wondered why there are no values for SVSHRVL in the SVM table.

     

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

    If i vary SVSMHRRL, it doesn't change anything.

    I put a break point on the NOP in SYSSNIV_SVMHIFG (SYSNMI_ISR). If i lower the voltage from 3.6 v, i reach the nop in SYSSNIV_SVMHIFG when the voltage fall down between 2.2 and 2.3 voltage. This happens for any value of SVSMHRRL and SVSHRV.

    It seems as you can not vary the threshold.

    Just to be sure, in did this change:

    PMMCTL0_H = PMMPW_H;                // PMM Password (enable write)
    SVSMHCTL &= ~SVSHE;                 // Disable High side SVS
    SVSMHCTL |= (SVSHRVL_3+3);

    .....

    I tried adding a number between 7 and 0 but nothing has changed.



  • 0 in reply to Carloalberto Torghele
    Guru 227245 points

    Carloalberto Torghele said:
    SVSMHCTL |= (SVSHRVL_3+3);

    Ignore SVSHRVL completely. You have disabled the SVS, so these bits are don't care.
    SVSMHRRL should be 0 on startup, so the initial threshold should be 1.62V..1.85V. Setting it to 3 should raise the trigger voltage to 2.2V..2.42V.

    How do you know when the interrupt happens? I assume you use the (de)bugger?

    I'd rather suggest enabling SVMHVLRIE too and switch on an LED on SVMHIFG and switch it off again on SVMHVLRIFG.
    You never know what happens with realtime events (including noise, bouncing and whatever) when you allow the debugger to halt the CPU and inspect the registers.

    There's a note in the datasheet regarding the SVSMHRRL values: The SVMH settings available depend on the VCORE (PMMCOREVx) setting. And indeed, ttable 2-4 tell that on (default) PMMCOREV==0, only 0 to 3 are available. It should, however, make a difference whether you use 0 or 3.

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

    ok thank you! Now everyhing it's clear.

    Rising PMMCOREV I'm able to set the threshold approximately at 3.2 v.

    For the issue that with the default PMMCOREV (0), varying SVSMHRRL does not produce any effect, i noticed that in order to fix it, i had to explicity initialize SVSMHCTL at its default start up value (0x4400). Without this initialization, it seems as SVSMHRRL it's alway set at 3 (2.2 v c.a.).

    That's my current SVM/SVS init code:

        PMMCTL0_H = PMMPW_H;                // PMM Password (enable write)
        SVSMHCTL = 0x4400;
        SVSMHCTL &= ~SVSHE;                 // Disable High side SVS
        SVSMHCTL |= 1;               
        SVSMLCTL &= ~(SVMLE+SVSLE);         // Disable Low side SVS/SVM
        PMMIFG &= ~SVMHIFG;
        PMMRIE = SVMHIE;                     // SVM high-side interrupt enabled.
        PMMCTL0_H = 0x00;                      // Wrong PMM Password (disable write)

     

    Thanks!

    Best regards,

    Carloalberto

  • 0 in reply to Carloalberto Torghele
    Guru 227245 points

    Carloalberto Torghele said:
    For the issue that with the default PMMCOREV (0), varying SVSMHRRL does not produce any effect, i noticed that in order to fix it, i had to explicity initialize SVSMHCTL at its default start up value (0x4400). Without this initialization, it seems as SVSMHRRL it's alway set at 3 (2.2 v c.a.).

    That's interesting. And probably something worth further investigation.

    Can you check whether the initial register value is really 0x4400 (while exhibiting the wrong behavior)? Or is it 0x4403? FI you have the 5510 device errata sheet, is it listed there ? (I don't have it ready)

     

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

    Before execute the code i posted above, if i do

    myReg = SVSMHCTL;

    and i put a break point after this istruction, in myReg I get 0x4400.

  • 0 in reply to Carloalberto Torghele
    Guru 227245 points

    Thanks. I'll post a documentation comment. Maybe someone will pay attention.

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

    Before you spend to much time on this issue, it's probably worth mentioning that the microcontroller in my board it's a X430F5510.

    In a couple of weeks we should have avaiable the new master of our board where we will mount proper MSP430. I can do the same test again.

    I do not want to change the mcu on my current board bacause it's the only board that I have at the moment. I do not want to risk to damage it, i need to go on on my project.

    If you think the test it's worth I'll let you know!

  • 0 in reply to Carloalberto Torghele
    Guru 227245 points

    Thanks for the update.

    Yes, if you could post the results then - I will not send a report until it is clear that the problem applies to the 'release version' of this MSP.

**Attention** This is a public forum