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.

FRAM CTPL Library not operating properly after coming out of LPM3.5

I'm Using the FRAM Utility Library version 02.00.00.15.  I just got all the files to compile and all seems ok until I come out of LPM3.5.  I'm having problem getting my target to operate properly after coming out of LPM3.5, one of my peripheral devices, which was powered off is not communicating with the micro (FR5969) so I'm following the debugging advice in section 2.2.2 of the manual and defining CTPL_LPM_DEBUG in the Assembler Preprocessor window under IAR Embedded Workbench (IAR Assembler for MSP430 6.40.1 (6.40.1.950)).

The problem I ran into is errors in ctpl_low_level.s43.

Building configuration: target - Debug
Updating build tree...
ctpl_low_level.s43
Error[431]: Accessing SFR using incorrect size \fram_utils\ctpl_low_level.s43 127
Error[431]: Accessing SFR using incorrect size \fram_utils\ctpl_low_level.s43 127
Error[50]: Undefined symbol:'__STACK_END'      \fram_utils\ctpl_low_level.s43 127
Error[50]: Undefined symbol:'lpmDebug_return'  \fram_utils\ctpl_low_level.s43 127
Error[444]: PC offset must be even.            \fram_utils\ctpl_low_level.s43 127
Error[444]: PC offset must be even.            \fram_utils\ctpl_low_level.s43 127
Error while running Assembler
 
Total number of errors: 6
Total number of warnings: 0

Here's the MACRO code:

; Allow debugging in LPMx.5 by emulating wakeup
lpmDebug    MACRO
#if defined(CTPL_LPM_DEBUG)
        movx.a  #CTPL_RAM_START,R4                  ; fill dst
        movx.a  #(__STACK_END-CTPL_RAM_START),R5    ; fill length
        movx.a  #0xffff,R6                          ; fill value
        fillx   R4,R5,R6                            ; fill RAM contents with 0xffff
        LOCAL lpmDebug_top

So I defined __STACK_END as 2400h since CTPL_RAM_START was defined as 1c00h. This didn't fix the issue. The naming of __STACK_END is ???? Isn't the end of the stack the same place the RAM starts, since the stack starts at the top of RAM and works down?

I didn't see anyone else having this issue. Please help.

Thanks,

-Jim

  • Here's some more...

    The problem is in the coding of the macro of RTC_B... There's issues there.

    But looking at the code and linker file, I do not see where you save all 2048 bytes of RAM. Could you shed a light on this?
  • Hi Jim,

    I've looped in our software engineers about this issue. They will be responding shortly.

    Regards,

    James

    MSP Customer Applications
  • Hi Jim,

    I'm able to reproduce the same errors you're seeing in IAR. I need to get a better understanding of the issue and will continue to look into this next week. I'll be sure to keep you updated with any findings or fixes.

    Regards,

    Brent Peterson

  • Hi Jim,

    It looks like there were a few errors in translating the CTPL_LPM_DEBUG code from CCS assembly syntax to IAR. The attached "ctpl_low_level_macros.m43" should now be correct, I'm able to compile and run it on my system.  Can you please try to compile with the attached version and let me know if this fixes the issue on your end?

    Thank you,

    Brent Peterson

    ctpl_low_level_macros.txt
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    ; Call statement for different code models
    callx MACRO src
    #if defined(__LARGE_CODE_MODEL__)
    calla src
    #else
    call src
    #endif
    ENDM
    ; Return statement for different code models
    retx MACRO
    #if defined(__LARGE_CODE_MODEL__)
    reta
    #else
    ret
    #endif
    ENDM
    ; Define DMA if using DMA3
    #if defined(__MSP430_HAS_DMAX_3__)
    __MSP430_HAS_DMA__ EQU 1
    #endif
    ; Macro for performing copy with either CPU or DMA
    copyx MACRO src, dst, len
    #if defined(__MSP430_HAS_DMAX_3__)
    clr.b &DMA0CTL_L ; sw trigger, channel 0
    movx.a src,&DMA0SA ; set src address
    movx.a dst,&DMA0DA ; set dst address
    rra.w len ; divide length by 2
    mov.w len, &DMA0SZ ; set copy size
    mov.w #DMASWDW+DMADT_1+DMASRCINCR_3+DMADSTINCR_3+DMAEN+DMAREQ,&DMA0CTL ; trigger DMA copy
    #else
    LOCAL ctpl_copyLoop
    ctpl_copyLoop:
    movx.w @src+, 0(dst) ; copy stack word and increment src ptr
    addx.a #2,dst ; increment dst ptr
    subx.a #2,len ; decrement stack usage
    jnz ctpl_copyLoop ; loop if usage > 0
    #endif
    ENDM
    ; Macro for performing fill with either CPU or DMA
    fillx MACRO dst, len, val
    #if defined(__MSP430_HAS_DMA__)
    movx.w val,0(dst) ; fill first value
    clr.b &DMA0CTL_L ; sw trigger, channel 0
    movx.a dst,&DMA0SA ; set src address
    movx.a dst,&DMA0DA ; set dst address
    rra.w len ; divide length by 2
    mov.w len, &DMA0SZ ; set fill size
    mov.w #DMASWDW+DMADT_1+DMASRCINCR_0+DMADSTINCR_3+DMAEN+DMAREQ,&DMA0CTL ; trigger DMA fill
    #else
    LOCAL ctpl_fillLoop
    ctpl_fillLoop:
    movx.w val,0(dst) ; fill dst
    addx.a #2,dst ; increment dst ptr
    subx.a #2,len ; decrement stack usage
    jnz ctpl_fillLoop ; loop if usage > 0
    #endif
    ENDM
    ; Macro for configuring DCO for shutdown
    configureDcoShutdown MACRO div
    #if defined(__MSP430FR2XX_4XX_FAMILY__)
    bic.w #SCG0,SR ; disable FLL
    mov.w #DIVM__32+DIVS__1,&CSCTL3 ; Set maximum dividers
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • Okay...
    Awesome. Thanks. I'll try it and see...
    I've posted another issue with the FRAM Library regarding not implementing the AES save/restore functions. I'd love to see this added. It must of been an oversight. BTW, great job on the library. It works great so far. But please see my post regarding this issue since I added a couple other things.
    Thanks,
    -Jim

**Attention** This is a public forum