• State
  • Locked Locked
  • Replies 11 replies
  • Subscribers 79 subscribers
  • Views 518 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

Help porting ctpl library to gcc

MSP430FR5994: Help in porting Compute through power loss Fram utility with GCC compiler for MSP430FR5994

Vishak Narayanan
Prodigy 20 points
Part Number: MSP430FR5994

I am trying to port the Compute through power loss FRAM utility using the GNU v8.3.0.16 compiler for the MSP430FR5994.

Through this thread I came to know that The two components that would need to be ported from the TI compiler to GCC are the the linker files (placing all RAM data into FRAM with the exception of the stack) and the low-level assembly routine. I have updated the low level assembly file and with the default linker for the 5994,

I was able to compile the example code from the resource explorer(The internal ADC monitoring for checkpointing) but the code doesn't seem to work. The GPIO toggling is itself indifferent. 

Through this thread , I was able to recolonize the issues and tried to modify the linker files(wrt the 5994 device) and even for the watchdog timer issue, but for some reason it just doesn't compile with the updated linker file. (I did this comparing the linker file from the example code , which compiles with the TI compiler)

I have attached the project here ctpl_with_gcc_debug.zip - which is with the default linker.

The updated linker file which doesn't compile is this  

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/* ============================================================================ */
/* Copyright (c) 2015, Texas Instruments Incorporated */
/* All rights reserved. */
/* */
/* Redistribution and use in source and binary forms, with or without */
/* modification, are permitted provided that the following conditions */
/* are met: */
/* */
/* * Redistributions of source code must retain the above copyright */
/* notice, this list of conditions and the following disclaimer. */
/* */
/* * Redistributions in binary form must reproduce the above copyright */
/* notice, this list of conditions and the following disclaimer in the */
/* documentation and/or other materials provided with the distribution. */
/* */
/* * Neither the name of Texas Instruments Incorporated nor the names of */
/* its contributors may be used to endorse or promote products derived */
/* from this software without specific prior written permission. */
/* */
/* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" */
/* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Any help would be greatly appreciated.

  • 0
    TI__Mastermind 49692 points

    Hello,

    The MSP430 GCC Toolchain User’s Guide should be a good resource for this exercise.

  • 0
    Prodigy 20 points

    Thanks for the reply James. I have been able to successfully compile the low level assembly file but could you please give me an insight of the specific changes that has to be done on the linker file, in order to successfully port the ctpl on to work with the GCC. sorry I am a bit new to the linker scripts.

  • 0 in reply to Vishak Narayanan
    Guru 22705 points

    Your modified linker script references the symbol "ROM" which isn't defined. (Typically used on flash parts.) The original version uses "FRAM".

  • 0 in reply to David Schultz
    Guru 22705 points

    Expanding on that a bit, here is part of the script:

    Fullscreen
    1
    2
    3
    4
    5
    6
    .lower.data :
    {
    . = ALIGN(2);
    PROVIDE (__datastart = .);
    *(.lower.data.* .lower.data)
    } > RAM AT> FRAM
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    The reason for this is that while the variables live in RAM their initial values are stored in FRAM. The startup routines copy the initial values.

    It would appear that what you need is ">FRAM AT> FRAM". Kind of redundant and it wastes space but disabling the copy of initial values would require a dive into the startup code. The manual (slau646) describes how to insert functions into the initialization sequence to disable the watchdog but doesn't say anything about replacing or disabling existing routines.

    You probably also want to change the bss from RAM to FRAM since uninitialized variables live there.

  • 0
    Prodigy 20 points

    Thanks a lot David, let me try your suggestion and see it out. so would you suggest me using the default linker file that you get with a gcc project and modifying it to have >FRAM AT> FRAM disabling the copy of initial values and change the bss from RAM to FRAM

  • 0
    Prodigy 20 points

    And I guess the Heap should be placed on the FRAM and the stack should remain in the RAM?  Like in the code snippet below. Also should I split the FRAM into two spaces(for read and write) and how can this be linked with the ctpl library then?

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    .heap (NOLOAD) :
    {
    . = ALIGN(2);
    __heap_start__ = .;
    _end = __heap_start__;
    PROVIDE (end = .);
    KEEP (*(.heap))
    _end = .;
    PROVIDE (end = .);
    /* This word is here so that the section is not empty, and thus
    not discarded by the linker. The actual value does not matter
    and is ignored. */
    LONG(0);
    __heap_end__ = .;
    __HeapLimit = __heap_end__;
    } > ROM
    /* WARNING: Do not place anything in RAM here.
    The heap section must be the last section in RAM and the stack
    section must be placed at the very end of the RAM region. */
    .stack (ORIGIN (RAM) + LENGTH(RAM)) :
    {
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0
    Prodigy 20 points

    At the same time I am using the below code snippet in the low level assembly file but the compiler always gives me an error saying  ../fram-utilities/ctpl/ctpl_low_level.s:126: Error: extra characters '(((0x0080)+(0x0040)+(0x0020)+(0x0010)))' at end of immediate expression '#__bis_SR_register(((0x0080)+(0x0040)+(0x0020)+(0x0010)))'.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    ctpl_enterLpm:
    benchmark ; Toggle the CTPL benchmark pin
    lpmDebug ; Optional LPMx.5 debug mode*
    mov.b #PMMPW_H,&PMMCTL0_H ; Set LPMx.5 bit
    mov.b #PMMREGOFF,&PMMCTL0_L ; Set LPMx.5 bit
    bis.w #LPM4, SR /*# Enter LPMx.5 mode*/
    nop
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Could anyone help me with this as well as to why that happens?

  • 0 in reply to Vishak Narayanan
    Guru 22705 points

    Did you define __STDC__ somewhere in that assembly language file? The 5994.h file uses that symbol to select between definitions of LPM4 suitable for the assembler or C. You got the C version.

  • 0
    Prodigy 20 points

    Thanks for the info David. No I haven't defined the __STDC__ macro in the assembly file. 

  • 0 in reply to Vishak Narayanan
    Prodigy 20 points

    I have attached my overall implementation here ctpl_with_gcc.zip. Could you just help me debug this and see if I am completely doing it wrong?

  • 0 in reply to Vishak Narayanan
    Guru 22705 points

    It was defined somewhere. If you can't track down where, then you could use the C version for LPM4 which is LPM4_bits.

**Attention** This is a public forum