• State Resolved
  • Locked Locked
  • Replies 33 replies
  • Answers 1 answer
  • Subscribers 79 subscribers
  • Views 24607 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.

Debugging Application with MSPBoot

Deep Anand
Intellectual 570 points
Other Parts Discussed in Thread: MSP430FR5969, MSPBSL, MSP-GANG

Hello Luis,

Now I am trying to build and debug App1_MSPBoot (MSPBoot is already flashed to controller). I changed the cmd file for MSP430FR5969 accordingly (file attached for your reference). But when I start debugging.... application starts running immediately with Resume(F8) button disabled.... and when I suspend execution (Alt+F8) it says No source available for "0x4". Additionally the application is not doing what it is supposed to do (toggling P4.7 pin).

Regards,

Deep

lnk_msp430fr5969_App.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
/* ============================================================================ */
/* Copyright (c) 2014, 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, */
/* THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR */
/* PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR */
/* CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, */
/* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, */
/* PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; */
/* OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, */
/* WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR */
/* OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, */
/* EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. */
/* ============================================================================ */
/******************************************************************************/
/* lnk_msp430fr5969.cmd - LINKER COMMAND FILE FOR LINKING MSP430FR5969 PROGRAMS */
/* */
/* Usage: lnk430 <obj files...> -o <out file> -m <map file> lnk.cmd */
/* cl430 <src files...> -z -o <out file> -m <map file> lnk.cmd */
/* */
/*----------------------------------------------------------------------------*/
/****************************************************************************/
/* SPECIFY THE SYSTEM MEMORY MAP */
/****************************************************************************/
/* The following definitions can be changed to customize the memory map for a different device
* or other adjustments
* Note that the changes should match the definitions used in MEMORY and SECTIONS
*
*/
/* RAM Memory Addresses */
__RAM_Start = 0x1C00; /* RAM Start */
__RAM_End = 0x1FFF; /* RAM End */
/* RAM shared between App and Bootloader, must be reserved */
PassWd = 0x1C00; /* Password sent by App to force boot mode */
StatCtrl = 0x1C02; /* Status and Control byte used by Comm */
CI_State_Machine = 0x1C03; /* State machine variable used by Comm */
CI_Callback_ptr = 0x1C04; /* Pointer to Comm callback structure */
/* Unreserved RAM used for Bootloader or App purposes */
_NonReserved_RAM_Start = 0x1C06; /* Non-reserved RAM */
/* Flash memory addresses */
/* Download area: C200-DDFF*/
/* App area : DE00-F9FF*/
/* Boot area : FA00-FFFF*/
_FLASHDOWN_START = 0xC200; /* Start if download area */
__Flash_Start = 0xDE00; /* Start of Flash */
__Flash_End = 0xFFFF; /* End of Flash */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0
    TI__Genius 16840 points
    Hi Deep,

    I created a new thread for this question. It's difficult for us to track updates to threads that have been already answered.

    Is CCS mass-erasing the device when you download the application? Try loading the bootloader first, then load the application using a different Debugger Download Option (i.e. "Replace Written Memory locations, retain Unwritten memory locations").

    It's also important to remark that by default, CCS projects try to run and only stop when they hit main(). If your application doesn't go to main() (because it's in bootloader), then it won't stop automatically. You can disable the option to run to main(), so that the debugger stops at the first instruction after reset. Note that in your case, you seem to have erased the bootloader since the device is executing at an invalid memory.

    In order to debug this kind of issues, I recommend you to try to take a few steps back and try to trace the root cause of the problem.
    1) Check the reset vector, is it valid and pointing to the right location (in this case it should point to the start of the bootloader)
    2) Try resetting the device in the debugger (with "Run to Main" disabled) and you should start executing at this first instruction of the bootloader. Optionally, set the PC manually to this address
    3) The bootloader (if executing correctly) will decide to stay in bootloader mode or jump to application. If it stays in bootloader, can you see if the device gets stuck in a loop waiting for the packets? Or if it tries to jump to application, is it jumping to the right address?


    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    Thanks for your response. Answers to your points:

    1. I checked the reset vector it points to _c_int00

    2. yes it starts executing at _c_int00

    3. it is stuck in the loop waiting for the packets.

    Additionally I tried to create the C array (size 7KB) of the APP1 and tried to flash it using TI_MSPBoot_MI_WriteByteDirect() in the main(). With this I could not build the project and was getting error #10099-D: program will not fit into available, I suppose it was because of its size (7KB). Can you please suggest if there is some other way to do it? Attaching array.c file.

    Regards,

    Deep

    AppForHost.c
    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
    //
    // Filename: AppForHost.c
    // Generated from msp430fr59xx_1_CRC.txt
    // Mon Jun 8 11:06:20 2015
    #include <stdint.h>
    #define App1Array_SIZE 7168
    const uint16_t App1Array_Addr[1] = {
    0xde00, // Address segment0
    };
    const uint16_t App1Array_Size[1] = {
    7168, // Size segment0
    };
    const uint8_t App1Array_0[] = {
    0x86,0xc4,0xff,0xff,0x2a,0x14,0x40,0x18,0x1a,0x42,0x5c,0x01,0x8f,0x00,0x00,0x00,
    0x9f,0x00,0x00,0x00,0x13,0x24,0x89,0x00,0x00,0x00,0x88,0x00,0x00,0x00,0x0c,0x3c,
    0x0c,0x09,0x7f,0x4c,0x5f,0x06,0x00,0x18,0x5f,0x4f,0x00,0x00,0xa9,0x00,0x04,0x00,
    0x0d,0x09,0x4f,0x13,0xa9,0x00,0x04,0x00,0xd9,0x08,0xf2,0x23,0x7a,0xc2,0x3a,0xd0,
    0x08,0x5a,0x40,0x18,0x82,0x4a,0x5c,0x01,0x8f,0x00,0x00,0x00,0x9f,0x00,0x00,0x00,
    0x09,0x24,0x8a,0x00,0x00,0x00,0x03,0x3c,0x6a,0x13,0xaa,0x00,0x04,0x00,0x9a,0x00,
    0x00,0x00,0xfa,0x23,0x28,0x16,0x10,0x01,0xb2,0x40,0x80,0x5a,0x5c,0x01,0xd2,0xc3,
    0x02,0x02,0xd2,0xd3,0x04,0x02,0x92,0xc3,0x30,0x01,0xd2,0xe3,0x02,0x02,0x0d,0x14,
    0x3d,0x40,0x32,0x82,0x1d,0x83,0xfe,0x23,0x0d,0x16,0xf7,0x3f,0x03,0x43,0x81,0x00,
    0x00,0x20,0xb0,0x13,0xae,0xde,0x0c,0x93,0x02,0x24,0xb0,0x13,0x04,0xde,0x0c,0x43,
    0xb0,0x13,0x68,0xde,0xb0,0x13,0xb2,0xde,0x32,0xd0,0x10,0x00,0xfd,0x3f,0x1c,0x43,
    0x10,0x01,0x03,0x43,0xff,0x3f,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,0xff,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Deep Anand
    TI__Genius 16840 points

    Have you tried single-stepping in assembly to check where it fails? If you have, when does it fail?

    Are you configuring the flash timing before calling the function? The FCTL2 register is configured in the EraseSector function

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    It worked, thanks for your support!! It was stuck at CRC checking.

    As mentioned in the last post that I had created the C array (size 7KB) of the APP1 and was getting error #10099-D: program will not fit into available. To overcome this issue I have just used 2 small arrays App1Array_0[181] and App1Array_1[51] and could finally run the code (main file is attached for your reference).

    1. One issue here is when I run the project thru debugger it runs with no problem. But with power-on the it behaves differently, the application is reset as soon as it jumps to the application (main file and command file is attached for your reference).

    2. Additionally I want to know, how I can use the existing BSL to upgrade the firmware via simple UART cable through PC. Is there any such tool available?

    Regards,

    Deep

     

    3362.main.c
    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
    /*
    * \file main.c
    *
    * \brief Main routine for the bootloader for FR5739
    *
    */
    /* --COPYRIGHT--,BSD
    * Copyright (c) 2012, 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,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    * --/COPYRIGHT--*/
    //
    // Include files
    //
    #include "msp430.h"
    #include "TI_MSPBoot_Common.h"
    #include "TI_MSPBoot_CI.h"
    #include "TI_MSPBoot_MI.h"
    #include "TI_MSPBoot_AppMgr.h"
    ////////////////////////////////////////////////////////////////////////////////////
    ///////////////////Deep TEST////////////////////
    #include <stdint.h>
    #define App1Array_SIZE 7168
    //const uint16_t App1Array_Addr[1] = {
    // 0xde00, // Address segment0
    //};
    //
    //const uint16_t App1Array_Size[1] = {
    //7168, // Size segment0
    //};
    uint8_t App1Array_0[] = {
    0x86,0xc4,0xff,0xff,0x2a,0x14,0x40,0x18,0x1a,0x42,0x5c,0x01,0x8f,0x00,0x00,0x00,
    0x9f,0x00,0x00,0x00,0x13,0x24,0x89,0x00,0x00,0x00,0x88,0x00,0x00,0x00,0x0c,0x3c,
    0x0c,0x09,0x7f,0x4c,0x5f,0x06,0x00,0x18,0x5f,0x4f,0x00,0x00,0xa9,0x00,0x04,0x00,
    0x0d,0x09,0x4f,0x13,0xa9,0x00,0x04,0x00,0xd9,0x08,0xf2,0x23,0x7a,0xc2,0x3a,0xd0,
    0x08,0x5a,0x40,0x18,0x82,0x4a,0x5c,0x01,0x8f,0x00,0x00,0x00,0x9f,0x00,0x00,0x00,
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    lnk_msp430fr5969.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
    /******************************************************************************/
    /* LINKER COMMAND FILE FOR MSPBoot BOOTLOADER USING MSP430FR5969 */
    /* File generated with MSPBootLinkerGen.pl on 04-24-2015 */
    /*----------------------------------------------------------------------------*/
    /****************************************************************************/
    /* SPECIFY THE SYSTEM MEMORY MAP */
    /****************************************************************************/
    /* The following definitions can be changed to customize the memory map for a different device
    * or other adjustments
    * Note that the changes should match the definitions used in MEMORY and SECTIONS
    *
    */
    /* RAM Memory Addresses */
    __RAM_Start = 0x1C00; /* RAM Start */
    __RAM_End = 0x1FFF; /* RAM End */
    /* RAM shared between App and Bootloader, must be reserved */
    PassWd = 0x1C00; /* Password sent by App to force boot mode */
    StatCtrl = 0x1C02; /* Status and Control byte used by Comm */
    CI_State_Machine = 0x1C03; /* State machine variable used by Comm */
    CI_Callback_ptr = 0x1C04; /* Pointer to Comm callback structure */
    /* Unreserved RAM used for Bootloader or App purposes */
    _NonReserved_RAM_Start = 0x1C06; /* Non-reserved RAM */
    /* Flash memory addresses */
    /* Download area: C200-DDFF*/
    /* App area : DE00-F9FF*/
    /* Boot area : FA00-FFFF*/
    _FLASHDOWN_START = 0xC200; /* Start if download area */
    __Flash_Start = 0xDE00; /* Start of Flash */
    __Flash_End = 0xFFFF; /* End of Flash */
    /* Reserved Flash locations for Bootloader Area */
    __Boot_Start = 0xFA00; /* Boot flash */
    __Boot_Reset = 0xFFFE; /* Boot reset vector */
    __Boot_VectorTable = 0xFF90; /* Boot vector table */
    __Boot_SharedCallbacks_Len = 8; /* Length of shared callbacks (2 calls =4B(msp430) or 8B(msp430x) */
    __Boot_SharedCallbacks = 0xFF88; /* Start of Shared callbacks */
    /* Reserved Flash locations for Application Area */
    _AppChecksum = (__Flash_Start); /* CRC16 of Application */
    _AppChecksum_8 = (__Flash_Start+2); /* CRC8 of Application */
    _App_Start = (__Flash_Start+3); /* Application Area */
    _App_End = (__Boot_Start-1); /* End of application area (before boot) */
    _CRC_Size = (_App_End - _App_Start +1); /* Number of bytes calculated for CRC */
    _App_Reset_Vector = (__Boot_Start-2); /* Address of Application reset vector */
    _App_Proxy_Vector_Start = 0xF990; /* Proxy interrupt table */
    // Addresses for Dual Image support in download ares
    _AppChecksumDown = (_FLASHDOWN_START);
    _AppChecksumDown_8 = (_FLASHDOWN_START+2);
    _App_StartDown = (_FLASHDOWN_START+3);
    _App_EndDown = (__Flash_Start-1);
    /* MEMORY definition, adjust based on definitions above */
    MEMORY
    {
    SFR : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
    // RAM from _NonReserved_RAM_Start - __RAM_End
    RAM : origin = 0x1C06, length = 0x3FA
    INFOBOOT : origin = 0x1800, length = 0x100
    // Flash from __Boot_Start -( __Boot_SharedCallbacks or INT_VECTOR_TABLE)
    FLASH : origin = 0xFA00, length = 0x588
    // Shared callbacks from __Boot_SharedCallbacks + Len (when used)
    BOOT_SHARED_CALLBACKS : origin = 0xFF88, length = 8
    // Boot vector Table from __Boot_VectorTable- __Boot_Reset
    INT_VECTOR_TABLE : origin = 0xFF90, length = 0x6E
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

  • 0 in reply to Deep Anand
    TI__Genius 16840 points

    Hi Deep,

    Deep Anand said:
    1. One issue here is when I run the project thru debugger it runs with no problem. But with power-on the it behaves differently, the application is reset as soon as it jumps to the application (main file and command file is attached for your reference).

    Do you see this problem at the end of the download, or at the beginning of the bootloader execution when it decides to jump to application? 

    Try connecting to the device with "Debug without Downloading". Then go to the reset vector and start single-stepping. Is the application reset vector in the correct location?

    Deep Anand said:

    2. Additionally I want to know, how I can use the existing BSL to upgrade the firmware via simple UART cable through PC. Is there any such tool available?

    The code includes Host examples using MSP-EXP430G2 and MSP-EXP430F5438, but they work standalone and not through UART with the PC. In theory, a low-cost tool like the MSP-EXP430G2 or MSPBSL (http://www.ti.com/tool/MSPBSL

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hello Luis,

    According to your last reply I tried debugging without download and found different behavior.  I see this problem at the beginning of the bootloader execution when it decides to jump to application. I have created a document with snapshots explaining the problem.

    The document shows the difference isDebugWithoutDownload.docx in between step 3 of ‘Debug with load symbols only’ and step 3 of ‘Debug with load program’. In ‘Debug with load symbols only’ (debug without download) the jump to Application is not happening. As in ‘Debug with load program’ (debug with download) the jump to Application is correct.

    I have attached the document as well as the code for your reference.

    Regards,

    Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    From the screenshots, I can see that you are not validating the Application, not even by checking if the vector is valid, but the device just tries to jump to it and in the first case, the vector is invalid.

    In order to reduce the footprint, MSPBoot overrides the default startup sequence from CCS/IAR. You can see that because the project includes boot.c (CCS) or cstartup.s43 (IAR). One of the consequences of this action is that the startup sequence doesn't initialize RAM variables (to zero, or to a default value).
    In the default startup sequence, you can usually assume that by the time you execute main(), all your non-initialized variables are zero, and all your initialized variables are initialized properly (with values which are copied from Non-volatile memory); but in this case, you can't assume that and I can see that your arrays are in RAM, but nothing is initializing them after reset.

    Try making those array const instead.

    I also see that you are initilaizing "i" and "addr1" (which doesn't have any effect), but then you initialize them again in main(). So those are OK.

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    Now that I am writing MSPBOOT according to MSP430FR5969. I need your expert suggestions before starting it.

    1. My requirement is to have two partitions of 24KB for dual Applications. The memory map What I decided if as:

    /* Flash memory addresses */

    /* Download area: 4400-C3FF*/

    /* App area : C400-139FF*/

    /* Boot area : 13A00-13FFF*/

    is that the correct decision according to you?

    2. Additionally I doubt that generated cmd files too if they are correct from the script as INT_VECTOR_TABLE length is mentioned as 0xFFFFC06E in Boot cmd file (INT_VECTOR_TABLE        : origin = 0x13F90, length = 0xFFFFC06E)?? I am attaching both Boot and App cmd files for your reference.

    3. Very important question, what are the changes I need to do in MSPBOOT to make it work for 64KB of memory??

     

    Thanks & Regards,

    Deep Anand

     

     output.zip

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    1. Bootloaders can be created in many different ways to meet particular needs but it's important to remember that the MSP430 always has the reset vector in 0xFFFE, and this last sector also has the interrupt vectors and other important stuff like JTAG signatures.
    MSPBoot resides in this sector and adjacent sectors at the top of the 16-bit memory map (i.e. FE00-FFFF when using 512B, or 0xFC00-FFFF when using 1KB).
    The idea is that the reset vector ALWAYS jumps to the same location in the bootloader, and the whole bootloader area is protected and never gets erased.
    Of course, that brings the problem of the interrupts, which can't be rewritten in Flash devices without erasing the Reset vector, so that's why MSPBoot uses a proxy table in Flash devices. However, when using FRAM devices, that's not much of a problem because you don't need to erase the whole sector and MSPBoot simply overwrites all the interrupt vectors, except for the Reset vector.

    In conclusion, I would put the bootloader at the top of the 16-bit memory map.

    2 and 3: Unfortunately MSPBoot was first written for small MSP430 16-bit (not 430X with 20-bit bus). This is not the first time I get the request for support on bigger 20-bit devices but unfortunately, I haven't done the migration.
    The migration is very feasible and not that complicated. Some customers and E2E members have done it before and you can check their previous threads:
    e2e.ti.com/.../1363322
    e2e.ti.com/.../324839
    e2e.ti.com/.../1403077
    e2e.ti.com/.../1313055

    The issues I have seen include:
    - The linker files would have to be adjusted manually (or the scripts need to be modified to support 20-bits),
    - The proxy table was written for 16-bit memory pointers and it needs to be adjusted. The proxy table is not needed for FRAM devices though (as shown in the FR57xx example included in SLAA600)
    - The Memory Interface API (Erase Sector, Write Byte, EraseApp) were written for 16-bits instead of 20-bits.


    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    First of all thanks for your reply!!

    Even I thought of the same way as your suggestion but wouldn't there be a problem if suppose later on the size of my application changes (Main: code memory::013FFFh-004400h)?? Additionally I will not get the continuous memory for one of the application......

    So, instead I am thinking to implement the memory map as below:

    /* Flash memory addresses *
    /* Download area: A3A0-FB9F*/
    /* App area     : 4BA0-A39F*/
    /* Boot area    : 4400-4BFF*/

    In this case even if the size of my application increases, only the Download area will only enter 20 bit address. The only thing I need to take care is to protect the RESET vector. Is my memory map above correct according to you or do you foresee any issues with this memory map??

    One more thing I wanted t know, how MSPBoot and Application firmware can be flashed in the controller for the first time (e.g. while in manufacturing for mass production)?

    Regards,

    Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    You can use JTAG/SBW to program the device for the first time. Depending on your needs, you can either program both the bootloader and application at the same time, or you can only program the bootloader.

    Tools like MSP-GANG are very popular for production.
    This presentation is a little old but it talks about some of these options in more detail: focus.ti.com/.../msp430toolsfromdevelopmenttoproduction.pdf


    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    Thanks for your response regarding upgrade tools!!

    I still need your expert comments on my memory map, described in my previous post, please reply:

    /* Flash memory addresses *
    /* Download area: A3A0-FB9F*/
    /* App area     : 4BA0-A39F*/
    /* Boot area    : 4400-4BFF*/

    Regards,

    Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    The memory configuration is really up to you and your application needs, but I can only recommend you to try it, and adjust if needed.

    Personally, if I wanted or had to use more memory, I would make the necessary modifications to the bootloader to use >16-bits. I would put the App Area in <16-bits and I would probably break the download area (at least for this device since it only has 16KB contiguous from 10000-13FFF). And I see that you are already considering that based on your previous message.

    The only problem I see from your configuration is that the Boot Area overlaps with the App Area (0x4BA0-0x4BFF)

    I also see that you are dividing sections without minimum granularity.
    In Flash devices, you have a minimum erase granularity (i.e. 512B) which would force some boundary limits, but with FRAM you don't have that problem.
    However, something that you might also consider is the granularity of the MPU, in case you want to use it to protect your bootloader. The minimum granularity is 1KB and you can have 3 segments.

    The current bootloader for FR5739 uses one segment to protect bootloader and vectors (since they are contiguous), and only removes the protection of the area when it needs to update the vectors.

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    Thanks for your comments!!

    Further I moved one step ahead and tried to use a timer interrupt in the application (main file attached). The issue I am facing is.... when I configure the timer interrupt and enable the interrupts using '_enable_interrupts();' my application is resetting continuously. Timer ISR is never hit but the application is reset. The cmd files for both MSPBoot and Application are the default cmd files '5KB_Dual_Boot'. Could you please let me know what is going wrong?

    When I tried to debug the assembly it says no code available for 0xfb1c (Print screen attached) and this 0xfb1c is actually '_c_int00' of the bootlader (MSPBoot) (Print screen attached).

     

    I have also attached the application.

    Regards,

    Deep

    msp430fr59xx_1.c
    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
    /* --COPYRIGHT--,BSD_EX
    * Copyright (c) 2012, 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,
    * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
    * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
    * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
    * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
    * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
    * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
    * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
    * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
    * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    *
    *******************************************************************************
    *
    * MSP430 CODE EXAMPLE DISCLAIMER
    *
    * MSP430 code examples are self-contained low-level programs that typically
    * demonstrate a single peripheral function or device feature in a highly
    * concise manner. For this the code may rely on the device's power-on default
    * register values and settings such as the clock configuration and care must
    * be taken when combining code from several examples to avoid potential side
    * effects. Also see www.ti.com/grace for a GUI- and www.ti.com/msp430ware
    * for an API functional library-approach to peripheral configuration.
    *
    * --/COPYRIGHT--*/
    //******************************************************************************
    // MSP430FR59x Demo - Toggle P1.0 using software
    //
    // Description: Toggle P1.0 using software.
    // ACLK = n/a, MCLK = SMCLK = default DCO
    //
    // MSP430FR5969
    // ---------------
    // /|\| |
    // | | |
    // --|RST |
    // | |
    // | P1.0|-->LED
    //
    // T. Witt/ P. Thanigai
    // Texas Instruments Inc.
    // July 2013
    // Built with IAR Embedded Workbench V5.30 & Code Composer Studio V5.5
    //******************************************************************************
    #include <msp430.h>
    int main(void)
    {
    WDTCTL = WDTPW | WDTHOLD; // Stop WDT
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX


    msp430fr59xx_1.zip

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    - Start by checking the hardware interrupt vectors which should be in the appropriate location. I.e. according to the datasheet (www.ti.com/.../msp430fr5969.pdf), the TA0 vectors are in 0xFFE8 and 0xFFEA.

    Regardless of where you put your application, the vectors will always be in this location. As mentioned previously, the Flash implementation of MSPBoot redirects the vectors using a Proxy table, but the FRAM implementation simply overwrites them (except for the reset vector).

    If your application was written correctly by the bootloader, the vectors should be overwritten with the address of the interrupt routine of the application. If you see incorrect values, then the booloader is not writing the vectors properly.

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

     Yes I have enabled ISR for TA0 vector 0xFFEA. By writing below lines:
     
          TA0CCTL0 = CCIE;                          // TACCR0 interrupt enabled
          TA0CCR0 = 50000;
          TA0CTL = TASSEL__SMCLK | MC__UP;          // SMCLK, UP mode
          
     and for ISR I have used TIMER0_A0_VECTOR (#pragma vector = TIMER0_A0_VECTOR).
     
     I flashed the MSPBoot first using debugger and then flashed Main app again using debugger, so my Main application (App1) is not written by bootloader but by the debugger. Now when I debug my application and enter the _enable_interrupts() it says no code available for 0xfb1c which is '_c_int00' of the bootloader (MSPBoot).
     
     I understand that I need not to do any thing extra for vector redirection, is my understanding correct? Because after flasing the Main app the MSPBoot checks the CRC of the Main app and if it correct then it directly jumps to the application and does nothing specific to overwrite the interrupt vectors.

     In FRAM, MSPBoot overwrites the interrupt vectors but when updating the Download app to Main app not in the above use case.
     
     But while debugging the Main app I checked checked 0xFFEA in the memory browser and found the it 0xFF (attached the snapshot). Not able to figure out the problem.
     Hope I could explain my problem to you.
     
     Regards,
     Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points

    Hi Deep,

    I think you answered your own question.

    MSPBoot will "remap" the application interrupt vectors when it's receiving the new image, but the debugger doesn't do that automatically. 

    This happens on the following function:

    uint8_t TI_MSPBoot_MI_WriteByteDirect(uint16_t addr, uint8_t data)
{
    *(uint8_t *) addr = data;
    if ((addr >= APP_VECTOR_TABLE) && (addr < APP_RESET_VECTOR_ADDR))
    {
        // If address is an interrupt vector, copy directly to interrupt table
        addr = (addr - APP_VECTOR_TABLE) + BOOT_VECTOR_TABLE;
        MPUCTL0 = MPUPW | MPUENA;   // Enable access to MPU registers
        MPUSAM |= MPUSEG3WE;        // Enable Write access
        *(uint8_t *) addr = data;   // Write the vector
        MPUSAM &= ~MPUSEG3WE;       // Disable Write access
        MPUCTL0_H = 0x00;           // Disable access to MPU registers
    }
    return RET_OK;
}

    In your case, I assume that the debugger is placing the vectors in APP_VECTOR_TABLE and not in BOOT_VECTOR_TABLE.

    I didn't really anticipate this case, but perhaps something that can be done after reset is to make sure that both tables match.

    • A simple way to do it is just to copy everything from (APP_VECTOR_TABLE>= addr < APP_RESET_VECTOR_ADDR) to BOOT_VECTOR_TABLE;
    • optionally, you could compare them first, and only copy if necessary
    • or a third option that I can think of is to use an FRAM flag which is set only when the vectors are written by TI_MSPBoot_MI_WriteByteDirect

    I think something like this should work to copy the table:

    void TI_MSPBoot_CopyVectorTable(void)
{
	uint16_t v_addr;
	uint16_t p_addr;

    MPUCTL0 = MPUPW | MPUENA;   // Enable access to MPU registers
    MPUSAM |= MPUSEG3WE;        // Enable Write access

    for (v_addr = APP_VECTOR_TABLE; v_addr < APP_RESET_VECTOR_ADDR; v_addr+=2)
	{
    	p_addr = (v_addr - APP_VECTOR_TABLE) + BOOT_VECTOR_TABLE;
    	 *(uint16_t *) p_addr = *(uint16_t *) v_addr;   // Copy vector
	}
    MPUSAM &= ~MPUSEG3WE;       // Disable Write access
    MPUCTL0_H = 0x00;           // Disable access to MPU registers
}

    As you probably already saw, the application is validated and jumped to in the following instructions, so you would have to implement the "workaround" before jumping to the application;

    // Validate the application and jump if needed
    if (TI_MSPBoot_AppMgr_ValidateApp() == TRUE_t)
        TI_MSPBoot_APPMGR_JUMPTOAPP();

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 570 points
    Hi Luis,
    Can we use 'BSL_Scriptor' to program both MSPBoot and Application for the first time over UART?

    Regards,
    Deep
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hello Luis,

    I have defined the memory map as below:

    /* Download area: 4400-87FF and 10000-12C00*/

    /* App area : 8800-F7FF*/

    /* Boot area : F800-FFFF*/

    I have attached the zip file containing the App and Boot cmd file. Can you please have a look and let me know if you foresee any problem?

    CMD_Files.zip

    Regards,

    Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points

    Hi Deep,

    I believe your memory map will look like this:

    1C00-1C05 RAM-Reserved Area
      1C00-1C01 RAM-Passwd
      1C02-1C02 RAM-StatCtrl
      1C03-1C03 RAM-CI_State_Machine
      1C04-1C05 RAM-CI_Callback_Ptr
    1C06-23FF RAM-nonReserved
    1800-19FF Info-Boot
    4400 87FF Flash-Download Area(17K)
      4400-4401 CRC16-Download
      4402-4402 CRC8-Download
      4403-87FF Download
    8800-F7FF Flash-Application Area(28K)
      8800-8801 CRC16-App
      8802-8802 CRC8-App
      8803-F78F App
      F790-F7FD Proxy Vector
      F7FE-F7FF App Reset vector
    F800-FF8F  
      F800-FF87 Flash-Bootloader Area
      FF88-FF8F Flash-Shared_Vectors
    FF90-FFFE Vectors
      FF90-FFFD Flash-IntVectors
      FFFE-FFFF Flash-Reset
    10000-11BFF Flash-Upper Download Area (11K)

    I think it looks good. You probably know this, but these are a few things that come to my mind:

    - Since you are dividing the download area, you need to split the application as you are programming it. If the bootloader gets data for the first 17KB (8800-CBFF) then it should place it in the first download area (4400-87FF); but if it gets something for the last 11KB (CC00-F7FF), then it should place it in the 2nd download area (10000-11BFF).

    - The CRC of the application stored in 8800 is checked for the Application area (8803-F7FF), but the bootloader will also check the CRC of the download area (to make sure that the download is valid). So, you'll need to calculate the CRC for 4403-87FF and then 10000-11BFF, with the result stored in 4400. 

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Prodigy 75 points

    Hello Luis!

    I am trying to download and use the latest version of MSPBoot along with your App Note SLAA600A. However, the link directs me to MSPBoot version 1.0 and I believe based on the App Note the latest version of MSPBoot should be at least 1.2. Can you please help with an updated link? Thanks a lot!

    Best regards,

    Bo

  • 0 in reply to Bopamo Osaisai
    TI__Genius 16840 points

    Hi Bo,

    The latest published version is 1.01.00.00 which is available here: 

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    Since you know that my download area is divided into to two parts. The second part is in large data memory.

    Can I use uint16_t getCRC(uint8_t *pmsg, uint16_t msg_size) function as it is and just change the first para type as uint16_t * (uint16_t getCRC(uint16_t *pmsg, uint16_t msg_size) ) to calculate the CRC??

    I tried it but in such case uint16_t getCRC(uint16_t *pmsg, uint16_t msg_size) and uint16_t crc16MakeBitwiseDwnld(uint16_t *pmsg, uint16_t msg_size, uint16_t *crc1) are giving different results.

    Regards,

    Deep

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,
    Since you know that my download area is divided into to two parts. The second part is in large data memory.

    Can I use uint16_t crc16MakeBitwise(uint8_t *pmsg, uint16_t msg_size) function as it is to calculate the CRC of download image in large data memory?

    Additionally I changed the MSPBoot to large data model but since then I am getting following error once I do Soft Reset:

    No source available for "__mspabi_srll_1() at D:/Deep\OHFPI\FwUpgrade\MSPBoot_Dual_Image\MSPBOOT\Target\FR5739_I2C\CCS\MSPBoot\BSLBased_DualImg\MSPBoot.out:{3} 0xffff{4}" 

    Regards,
    Deep

  • 0 in reply to Luis RC
    Prodigy 75 points
    Thanks a lot, Luis!
  • 0 in reply to Deep Anand
    TI__Genius 16840 points

    Hi Deep,

    It will be difficult to calculate the CRC of the download area using that function since it's expecting a contiguous memory region, and it initializes the CRC at the beggining.

    Additionally, the default small data memory model will use 16-bit pointers which will make it difficult to implement without changes.

    As you already saw, changing to a large memory model can solve the problem of the pointer, however, you need to make sure that you cast other pointers correctly.

    Since your application and the bootloader will always in 16-bits, I think it's better to use the small memory model, and just use intrinsics to access memory areas above 0xFFFF.

    Note that you only need to access regions larger than 16-bits when writing/erasing that half of the download region, and when calculating the CRC of the same region.

    I started working on the migration and I documented the step-by-step in the following document:

    Migrating_MSPBoot_FR5969.docx

    Here's the zip file with preliminary support for Wolverine. I only migrated the CCS project for FR5969 using I2C and dual-image mode. I also added support for the G2 host only.

    MSPBoot_Wolverine_1_01_00_01.zip

    I hope you find it useful.

    Regards,

    Luis R

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    This is definitely very helpful to me, Thanks!!

    I had one more question: I want to read the FW Version from the TI.txt file. So, I created a memory section like below:

    FW_VERS               : origin = 0x8803, length = 0x0002

    and then section like ,

    .fw_vars : {} > FW_VERS

    and in the main file I wrote the following lines:

    #pragma SET_DATA_SECTION(".fram_vars")
    unsigned char led_output = 0xA5;
    #pragma SET_DATA_SECTION()

    and I expected a entry on the output TI.txt file  like 

    @8803
    A5

    but I could not find this entry in the output txt file.

    I even tried the same thing with pragma directive

    //#pragma LOCATION( x , 0x8803 );
    #pragma location=0x8803
    uint16_t x = 0xABCD;

    but that also didn't work. I am using CCSv6 and MSP430FR5969. Can you please help me out for this.

    Regards,

    Deep

     

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Hi Deep,

    You should declare it as a const and the compiler is probably ignoring the variable if you are not using it in the code.

    Check this wiki processors.wiki.ti.com/.../Placing_Variables_in_Specific_Memory_Location_-_MSP430
    And you can also find information in the CCS User Guides: www.ti.com/lit/slau132

    Regards,
    Luis R
  • 0 in reply to Luis RC
    TI__Genius 16840 points
    Oh, and please open a new thread if you have new/unrelated questions

    LR
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hi Luis,

    I have moved bss data (1.5KB) to FRAM because the RAM was not sufficient. This is causing issue when calculating the CRC while validating the application after 2nd restart and further. This is because  all the bss data (moved to FRAM) in FRAM has changed and the CRC calculated now differs from stored CRC. I am writing this to get some idea to overcome this issue. The simplest idea could be to validate the App with Reset vector (CONFIG_APPMGR_APP_VALIDATE = 1). But this doesn't seem to be a good solution. Can you please suggest something to overcome this issue????


    Thanks & Best Regards,

    Deep

  • 0 in reply to Deep Anand
    TI__Genius 16840 points
    Reserve a section of FRAM for these variables, which is outside of the Application's code area, and the download area.
    The CRC for the application should be calculated only for the Code area and not for any data area.

    Regards,
    Luis R
  • 0 in reply to Luis RC
    Intellectual 570 points

    Hello Luis,

    Thanks for your response. I have made the changes accordingly in the Boot and App linker file. Can you please review them and let me know your comments?

    Thanks & Best  Regards,

    Deep

    LinkerNewBSS.zip

  • 0 in reply to Luis RC
    Intellectual 570 points

    Hello Luis,

    Can I somehow flash both Boot image and App image via UART (using BSL Scriptor etc)?

    Or any other means like creating Special App which flashes the Bootloader image first?

    Regards,

    Deep

**Attention** This is a public forum