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.

MSP430F5244: How to transfer to LPM by writing a value according to the desired LPM level to the SR register.

Part Number: MSP430F5244

Hi,

 

■ Request

I want to transfer to LPM by writing a value according to the desired LPM level to the SR register.

 

■ Inquiry content

Use the breakpoint and stop at line 77 of the C source below.

After that, when the program is restarted and the SR register is written, PUC occurs.

Please tell me how to resolve this error.

 

(Supplementary explanation)

The write instruction of the SR register described in the assembly code is a 20-bit arithmetic instruction (BISX.W).

From the following description, it seems that the 20-bit write-protection constraint of the SR register is not observed.

CCS version is ver 7.4.0.

Thanks,

Koki

  • Have you try to use this function:

     __bis_SR_register(LPM3_bits);       // Enter LPM3

    Hope it can helps you:

    /*---------------------------------------------------------------------------*/
    /* MSP430/430X Macros */
    /*---------------------------------------------------------------------------*/
    #define __get_interrupt_state() __get_SR_register()

    #define __low_power_mode_0() __bis_SR_register(0x18)
    #define __low_power_mode_1() __bis_SR_register(0x58)
    #define __low_power_mode_2() __bis_SR_register(0x98)
    #define __low_power_mode_3() __bis_SR_register(0xD8)
    #define __low_power_mode_4() __bis_SR_register(0xF8)
    #define __low_power_mode_off_on_exit() __bic_SR_register_on_exit(0xF0)

  • Hi,

    Thank you for your quickly reply.

      

    [Question1]

    In the previous question, SR_SET_DATA is an unsigned short type 16bit, but it seems that 20bit data was

    written to the SR register.

    Please tell me why this phenomenon happened.

    Also, Please tell me why the problem is solved when I write directly in hexadecimal.

     

    [Question2]

    After modifying the code described last time as follows, the problem no longer occurs.

    Is there any problem with this correction method?

      

    -Changes

    This is modified to assign to __bis_SR_register () via a static variable of type USHORT.

    Attach the correct working assembly of the changes.

    ============================================================

    #define SET_LP_MODE(x) __bis_SR_register(x) volatile static USHORT s_u2_sr_tmp_data;

    void LPM_vdSleepAndIntCtrl(void) {

       UCHAR u1_lpm_jg;

       DI();                                                                   /* Interrupt disabled */

       u1_lpm_jg = lpm_u1Control();                             /* LPM judgment */

       s_u2_sr_tmp_data = SR_SET_DATA[u1_lpm_jg];

       SET_LP_MODE( s_u2_sr_tmp_data );                    /* Interrupt enable & LPM transition*/

       /*Modified to write SR via USHORT type static variable and pass it to macro*/

       return;

    }

    ========================================================

    Thanks,

    Koki

  • Please see this BISX.W is used for 16 bit address-word handling. The reason why it use BISX.W is that the data is saved at 20-bit address. I think it may not caused by you writing a 20-bit value to SR.  

    I am not sure if set SR, you can only use BIS.W. My advice is that:

    1. Read the value of the SR in debug mode when using previous code. It can help you check if the SR is setting correctly.

    2. You can try the previous code with small memory model setting.

  • [Question1]

    What is the cause of the error in the previous code?

    [Question2]

    Please tell me why the problem is solved when the write value is written directly as a value.

    [Question3]

    I changed the description to the following code and ran this code.

    Result looks like this code worked fine.

    Is there a problem with this code?

    Please check it just in case.

    ============================================================

    #define SET_LP_MODE(x) __bis_SR_register(x) volatile static USHORT s_u2_sr_tmp_data;

    void LPM_vdSleepAndIntCtrl(void) {

       UCHAR u1_lpm_jg;

       DI();                                                                   /* Interrupt disabled */

       u1_lpm_jg = lpm_u1Control();                             /* LPM judgment */

       s_u2_sr_tmp_data = SR_SET_DATA[u1_lpm_jg];

       SET_LP_MODE( s_u2_sr_tmp_data );                    /* Interrupt enable & LPM transition*/

       /*Modified to write SR via USHORT type static variable and pass it to macro*/

       return;

    }

    ========================================================

    Thanks,

  • Hi,

    Do you have any update?

    Thanks,

  • About your question 1:

    Can you help me do this two tests. It can help me know why. Thank you very much.

    1. Read the value of the SR in debug mode when using previous code. It can help you check if the SR is setting correctly.

    2. You can try the previous code with small memory model setting.

    About your question 2:

    You can check the assembly example code with the your de-assembly code, it is same.

    About your question 3:

    The code is right.

  • >You can try the previous code with small memory model setting.

    In the previous code, when I tried to work after setting it to "small", no error occurred. (PUC did not occur)

    Below is the generated assembly.

    Code = large, Data = restricted (PUC occurred)

    Code = small, Data = small (PUC did not occur)

    Please tell me what is the cause.

  • Thank you for your help!

    Data = large means that the compiler will use large memory size to save data and the command will change at the same time.

    You can see that 0x05836 is 20bit address, 0xea84 is 16 bit address.

    This experiment helps know the route reason is you can not use BISx.W(20bit address command) to clear SR register.

    For why it happens, how MSP430 core analysis the command, sorry I don't know.

  • >This experiment helps know the route reason is you can not use BISx.W.

    1. Is it okay to recognize that an error has occurred because a 20-bit value was written to the SR this time?

      

    >For why it happens, how MSP430 core analysis the command, sorry I don't know. 

    2. The value written to SR is defined as unsigned short type 16-bit data.

    Why is a 20bit value written when compiling with code = large and data = restricted settings?

    If the data is not handled in the size defined by the type, I'm worried that other data will be okay.

    Please tell me in detail why this phenomenon occurred to prevent recurrence.

      

    Thanks,

    Koki 

  • Hi,

    Do you have any update?

    Thanks,

  • Hi Koki,

    It does not write a 20bit data in SR, it is written a 16bit data in SR.

    Please see the description of BISX. 0x05836  is a address, not a data.

    Eason

  • Thank you.

     

    In summary, both BISX and BIS write 16 bits to the SR.

    BISX has an error and BIS works fine.

     

    Is it prohibited to write to SR with BISX instruction?

    There was a description of a yellow frame in UG.

      

    Does "Note" mean that BISX should not be used?

    If so, please tell me the reason.

    Thanks,

  • I think yes.As you can find the explanation from the UG, I think the problem is solved.  I am sorry, I also don't know the reason. To know why, I think I need to refer to the guy who design the MSP430 core, actually, I can't find him.  

  • Thank you for your feedback.

    As a result of checking the SYSRSTIV Register, the cause of PUC was PMM password violation. 

    I need to know why PUC occurs due to PMM password violation.

    Do you have a hypothesis about this?

  • All I can show you is this:

  • I know that PUC is caused by PMM password violation.

    I want to know why PMM password violation happens when SR is written by BISX.W.

  • You have to be careful when interpreting SYSRSTIV. It returns values in priority order and not in order of occurrence. Unless you read it until it returns zero, there could be a flag left set.

  • >It returns values in priority order and not in order of occurrence.

    Does SYSRSTIV pass through the value of the high priority factor when multiple interrupts occur?

    Even so, as shown in the attachment, "PMM password violation" has the lowest priority except Reserved.

    So I think that this time the interrupt was caused by PMM password violation.

  • Hi Kiki,

    Here is the what PMM password violation. But I still can't know why this happens. Sorry, it is beyond my knowledge base. 

    Eason

**Attention** This is a public forum