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.

Run out of RAM only via Bootloader

Other Parts Discussed in Thread: MSP430F5436A, TMS320F28035

I am using CCS5 with the MSP430F5436A processor. I am trying to write a simple program that will run out of ram only. I will load this program via the MSP’s built in boot loader and then use the boot loaders goto command to start the program running in RAM. I do not want to erase or write any flash in the MSP430 while loading this RAM program.

This ram program is being loaded into an already programed MSP430 that contains the application software for our device in FLASH. This RAM program is for production test only and I want to load the program and run the program. Once the device is powered of and back on the regular application will run normally.

My problem is when I try to create a RAM only program in CCS using the command linker file it seems CCS always wants to create a RESET vector in flash. I have been able to get all the code and initialization for the RAM program to run out of RAM, but have not been able to prevent CCS from generating the RESET vector in FLASH. I could modify the HEX output file manually, but was wondering how to prevent this from within CCS.

Is there an example of how to create such a program that runs out of RAM only? The program only has to run via the boot loader and will not be using any interrupts or reset vectors.

  • Gary,

    i am not sure this matches 100% what you are looking for, but have you seen this?

    http://processors.wiki.ti.com/index.php/MSP430_FAQ#Running_Code_from_SRAM

  • This is not exactly what I want to do. I would like to load a program into ram and then run it without disturbing the flash. The flash already has the device code installed, but during a production test, I want to load a simple test program that runs out of RAM and then goes away when the power is removed. Then when the power is restored the system begins running the flash code. 

    I have started with the example code for the MSP430 that blinks an LED. I have modified the section part of the linker command file as below. 

    SECTIONS

    {

        .bss        : {} > RAM                /* GLOBAL & STATIC VARS              */

        .data       : {} > RAM                /* GLOBAL & STATIC VARS              */

        .sysmem     : {} > RAM                /* DYNAMIC MEMORY ALLOCATION AREA    */

        .stack      : {} > RAM (HIGH)         /* SOFTWARE SYSTEM STACK             */

     

        .text       : {} > RAM //: {}>> FLASH2 | FLASH     /* CODE                              */

        .text:_isr  : {} > RAM //: {} > FLASH              /* ISR CODE SPACE                    */

        .cinit      : {} > RAM //: {} > FLASH | FLASH2     /* INITIALIZATION TABLES             */

        .const      : {} > RAM //: {} > FLASH | FLASH2     /* CONSTANT DATA                     */

        .cio        : {} > RAM                /* C I/O BUFFER                      */

     

        .pinit      : {} > RAM //: {} > FLASH              /* C++ CONSTRUCTOR TABLES            */

        .init_array : {} > RAM //: {} > FLASH              /* C++ CONSTRUCTOR TABLES            */

        .mspabi.exidx : {} > FLASH            /* C++ CONSTRUCTOR TABLES            */

        .mspabi.extab : {} > FLASH            /* C++ CONSTRUCTOR TABLES            */

     

        .infoA     : {} > INFOA              /* MSP430 INFO FLASH MEMORY SEGMENTS */

        .infoB     : {} > INFOB

        .infoC     : {} > INFOC

        .infoD     : {} > INFOD

     

        /* MSP430 INTERRUPT VECTORS          */

        .int00       : {}               > INT00

        .int01       : {}               > INT01

    .
    .
    .

        .int61       : {}               > INT61

        .int62       : {}               > INT62

        .reset       : > RESET,     TYPE = DSECT /* not used, */// : {}               > RESET  /* MSP430 RESET VECTOR         */

    }

     

    /****************************************************************************/

    /* INCLUDE PERIPHERALS MEMORY MAP                                           */

    /****************************************************************************/

     

    -l msp430f5436a.cmd

    //End of linker command 

    When I try to load this program via JTAG the program loads, but does not know where to start running the code. It also seems to reprogram some flash because my device code stored in Flash does not run when I power off and back on the unit.

    I do something very similar with CCS and the C2000 processor we us in another product. The command linker looks like this

     

    PAGE 0 : 

       /* BEGIN is used for the "boot to SARAM" bootloader mode   */ 

       BEGIN      : origin = 0x000000, length = 0x000002 

       RAMM0      : origin = 0x000050, length = 0x0003B0 

       RAML0L1    : origin = 0x008000, length = 0x000C00 

       RESET      : origin = 0x3FFFC0, length = 0x000002 

       IQTABLES   : origin = 0x3FE000, length = 0x000B50     /* IQ Math Tables in Boot ROM */ 

       IQTABLES2  : origin = 0x3FEB50, length = 0x00008C     /* IQ Math Tables in Boot ROM */ 

       IQTABLES3  : origin = 0x3FEBDC, length = 0x0000AA  /* IQ Math Tables in Boot ROM */ 

     

       BOOTROM    : origin = 0x3FF27C, length = 0x000D44 

    PAGE 1 : 

       BOOT_RSVD   : origin = 0x000002, length = 0x00004E     /* Part of M0, BOOT rom will use this for stack */ 

       RAMM1       : origin = 0x000480, length = 0x000380     /* on-chip RAM block M1 */ 

       RAML2       : origin = 0x008C00, length = 0x000400 

     /*  RAML3       : origin = 0x009000, length = 0x001000*/ 

     PAGE 2 :  

       RAML3       : origin = 0x009000, length = 0x001000     /* on-chip RAM (L3) */ 

    SECTIONS

       /* Setup for "boot to SARAM" mode: 

          The codestart section (found in DSP28_CodeStartBranch.asm) 

          re-directs execution to the start of user code.  */ 

       codestart        : > BEGIN,     PAGE = 0 

       ramfuncs         : > RAMM0      PAGE = 0  

       .txt_hello           : > RAML0L1,   PAGE = 0 /*RAML0L1*/  

       .text            : > RAML0L1,   PAGE = 0 

       .cinit           : > RAMM0,     PAGE = 0 

       .pinit           : > RAMM0,     PAGE = 0 

       .switch          : > RAMM0,     PAGE = 0 

       .reset           : > RESET,     PAGE = 0, TYPE = DSECT /* not used, */ 

       .stack           : > RAMM1,     PAGE = 1 

       .ebss            : > RAML2,     PAGE = 1/*RAML1*/ 

       .econst          : > RAML2,     PAGE = 1 

       .esysmem         : > RAMM1,     PAGE = 1 

          BlockTransferBuffer1: > RAML3       PAGE = 2 

      /* IQmath           : > RAML0L1,   PAGE = 0*/ 

       IQmathTables     : > IQTABLES,  PAGE = 0, TYPE = NOLOAD

    //End of TMS320F28035 command linker file 

    In the C2000 command linker I can prevent the reset vector from being written to flash and use the codestart directive to give the ram program a starting vector.  This allows me to load and run this program via JTAG or the Bootloader and not disturb the flash. Once this device is power of and back on it runs the original code in flash as though I had never loaded the ram code. 

    I am trying to do the same thing with the MSP430, but am not sure how to get this ram code to run using JTAG and/or the Boootloader without effecting the flash. 

    I hope this helps. Any help or suggestions would be appreciated.

  • Gary,

    you can basically just modify the linker command file and put everything in RAM. Consider the following simple example which i just made (I am using CCS v5.5.):

    4431.test.zip

    As you can see, the project is using the modified lnk_msp430f5436a_all_ram.cmd instead the default one. In this modified linker command file, i defined two memory: RAM_DATA and RAM_CODE which resides all in SRAM memory of the device. The sections are then allocated to either one of these memories. One additional note is that i also move the RESET vector to the beginning of SRAM.

    After compilation, you can find that all code are now allocated in SRAM memory:

    @1c00
    9E 1C 2A 14 3F 40 00 00 3F 90 01 00 23 28 3F 40 
    00 00 3F 90 01 00 1E 28 3A 40 00 00 3A 80 00 00 
    3A 50 07 00 5A 09 39 40 00 00 3C 49 3D 49 3E 49 
    3F 49 C8 0C CB 0D 1C 53 0D 63 0F 18 4B 5B 00 18 
    4B D8 6B 4B 4B 4B 5B 06 00 18 5B 4B 00 00 4B 13 
    1A 83 EB 23 3F 40 00 00 3F 90 00 00 08 24 3A 40 
    00 00 02 3C 6A 13 2A 52 3A 90 00 00 FB 23 28 16 
    10 01 21 83 B2 40 80 5A 5C 01 D2 D3 04 02 D2 E3 
    02 02 B1 40 10 27 00 00 91 83 00 00 81 93 00 00 
    F6 27 FA 3F 03 43 1C 43 10 01 03 43 FF 3F 31 40 
    00 5C B0 13 96 1C 0C 93 02 24 B0 13 02 1C 0C 43 
    B0 13 72 1C B0 13 9A 1C 
    q

    You can try to analyze the generated .map file also to get the detail information. 

    Please mention using ISR is not considered here, and just to make things easier, i would recommend not to use interrupt but polling mechanism, since your intention is anyway just to make a test code.

    If you want to jump from flash to execute the RAM, you can just jump to the memory pointed out by the new reset vector:

    ((void (*)())0x1C00)();

    I hope this helps somehow.

  • This is what I was looking for. Thank you for the help. This method should work when I load it via the bootloader because I can jump to the code start location and it should run only out of RAM. I have not tried this yet because I need to write a windows program to perform the bootloading.

    However, when I try to load this using the MSP-FET430 USB debugger, I cannot get the program to run from my RAM .reset location. I set the debugger configuration to “Run to Symbol” main “On a program load or restart” and I also set the Download option under the “Debug Configuration, MSP430 Properties” window to “Replace written memory locations, retain unwritten memory locations”. This keeps Flash from being erased when entering debug mode.

    When I enter the debug mode the program seems to download, but it does not run to program main and the green run arrow is not highlighted. It actually starts running the devices flashed software. The debugger may be resetting the MSP430 and it uses the Flash vector reset location instead of the linker command file reset location. 

    I notice that in the C2000 linker command file they use the “codestart  : > BEGIN,     PAGE = 0 “ directive to tell the debugger where to jump to. I do not see a similar directive for the MSP430. Is it possible to get this program to run in debug mode?

  • I got it working with JTAG!

    I needed to clear the "Reset the Target on a program load or restart" in the Debug Configuration "Program/Memory Load Options". Once I done this, the program loaded and ran as expected. I can now run my test software without distubing the application code stroed in Flash.

    Thanks Leo. I could not have done it without you.  You are now my new TI Hero.

  • Just wanted to follow up in case anyone else needed to do the same thing I am doing. When I tried to load the code via the built in bootloader, the bootloader would not allow me to write to certain areas of RAM. Then It occurred to me that the bootloader is using some of the RAM for its operation. Once I moved my RAM program up to a higher location in RAM, the bootloader allowed me to load it and then once I set the program pointer to the code start location it begin running my RAM code.

    Another observation is that the blink LED sample code was running much faster than when I used the JTAG to load it. This is because the bootloader is cranking the system clock to a higher frequency. I now plan to study the bootloader source code to understand exactly what part of RAM is used and how it is setting up the system. This will allow me to better set up my RAM code.

    Once I complete my RAM test code, I will be able to run RAM code in a production unit or a field unit that will allow me to gain access to other processors in the system in order to bootload them and perform quick testing without disturbing the main application code.

  • Gary,

    glad to hear that you made it work, and thanks for all the valuable feedback you gave. Anyway, i think the fastest way to find out the RAM used by the bootloader is to examine the linker command file from the BSL source code. It is basically released together with the SLAA450: www.ti.com/lit/slaa450

**Attention** This is a public forum