How to specify entry point using CCSv5 and MSP430 linker v4.2.1

Thank you for your prompt reply!

We need our own entry point to save RAM to NVM on reboot due to firmware errors. For all but watchdog timeouts and key violations we can save state in an interrupt service routine. WDT and KEYV errors must determine boot cause and save state before the stack is initialized. __sytetem_pre_init(), as it must, gets called after the stack is initialized.

Unfortunately, my boot.c looks pretty much the same as the MSP-BOOT file.

The interesting thing is that this works perfectly well using the 4.1.5 toolchain.

Hi Steve,

Maybe something in your project setting would be needed as well. Your comment reminded me of something from earlier this year: I don't know if this could be related (it was talking about a later compiler version actually). I also know that MSP-BOOT involves some linker file modifications as well so you may want to inspect the custom linker files included with it as well.

I took a look at boot.c in the run time support library. I'm using a newer compiler version, but hopefully this hasn't changed much. I can find the rts library source code in my ccsv6 installation at C:\ti\ccsv6\tools\compiler\msp430_4.2.6\lib\src. Looking in boot.c, I see this:

/*****************************************************************************/
/* C_INT00() - C ENVIRONMENT ENTRY POINT                                     */
/*****************************************************************************/
#pragma CLINK(_c_int00)
CSTART_DECL _c_int00()
{
   STACK_INIT();
   
   /*------------------------------------------------------------------------*/
   /* Allow for any application-specific low level initialization prior to   */
   /* initializing the C/C++ environment (global variable initialization,    */
   /* constructers).  If _system_pre_init() returns 0, then bypass C/C++     */
   /* initialization.  NOTE: BYPASSING THE CALL TO THE C/C++ INITIALIZATION  */
   /* ROUTINE MAY RESULT IN PROGRAM FAILURE.                                 */
   /*------------------------------------------------------------------------*/
   if(_system_pre_init() != 0)  _auto_init();

   /*------------------------------------------------------------------------*/
   /* Handle any argc/argv arguments if supported by an MSP430 loader.       */
   /*------------------------------------------------------------------------*/
   _args_main();

   exit(1);
}

Then looking in boot.h, I see STACK_INIT() is really just defined as:

/*---------------------------------------------------------------------------*/
/* Macro to initialize stack pointer.  Stack grows towards lower memory.     */
/*---------------------------------------------------------------------------*/
#if defined(__LARGE_DATA_MODEL__)
#define STACK_INIT() __asm("\t   MOVX.A\t   #__STACK_END,SP")
#else
#define STACK_INIT() __asm("\t   MOV.W\t    #__STACK_END,SP")
#endif

So I think really the only thing that STACK_INIT() actually changes is the value of the SP register. You could simply change it back to wherever else you want (wherever maybe you know you have space in RAM to have stack while you are doing your copy to NVM?) in _system_pre_init, and I don't think that should really have changed anything in RAM.

As a note, this is actually what our new Compute Through Power Loss (CTPL) library does (it is part of our new MSP-FRAM-UTILITIES for FRAM devices). That library is using _system_pre_init to bypass our normal c-startup code variable initialization etc, because in that case we are wanting to copy the variables and peripheral states that we saved to FRAM as we were losing power back into the peripheral registers and RAM, rather than using initial startup values - this includes the stack being initialized to the same state it was in as we were losing power. So that library simply lets the STACK_INIT() call in _c_int00 occur, but then in _system_pre_init simply reinitializes the SP (and stack values in RAM) to whatever we'd saved.

Regards,

Katie

Katie,

Again, thank you for the quick response.

I do understand that STACK_INIT() only modifies the stack pointer, but the SP is the most important bit of state information that we are trying to preserve, as the purpose of saving RAM is for crash analysis. We absolutely must be able to specify our own entry point for this reason.

- Steve

Luis,

That was it! Thank You!

I do have another question. It seems the map file generated does not correctly indicate the "used" value in the memory configuration section:

MEMORY CONFIGURATION

name origin length used unused attr fill
---------------------- -------- --------- -------- -------- ---- --------
.
.
.
ACTIMG1 00006480 00009b00 00005bd0 00003f30 RWIX
.
.
.
.text.1 0 00009260 00002df2
.
.
.
0000c050 00000002 sdfsm.obj (.text:sdSetThreshold)

As you can see, the 2 bytes at c050 are in the unused space of ACTIMG1.

The reason this is important is that we have a post build tool that processes the map file in order to create a command file for hex430 to output an intel hex file with no holes. (This is necessary for building an over the air code download file, which needs to be as small as possible.) I am using version 4.2.1 of the toolchain. Has this been fixed in a subsequent release?

Hi Steve,

I wasn't aware of this issue and I don't see any relevant bugs getting fixed in the release notes.
However, I can't replicate the problem with both CCS 6.1 or CCS 5.5. Do you have a code snippet?

You are not using absolute memory placement right? I can how placing a constant variable in an absolute memory location can cause such overlap, but if you are not doing that, then this definitively looks like a linker bug. The CCS E2E forum might be a better place to get an answer in such case.


And just as an additional comment, when you mention that you want to create an hex file output with no holes, do you mean filling all unused memory? What about using something like:
FLASH : origin = 0x5C00, length = 0xA380, fill = 0x3FFF


Regards,
Luis R

Luis,

No, we are not using absolute memory placement. I will post about this issue to the CCS E2E forum.

When I say no holes, I mean unused space not output to the Intel hex file created by hex430. An additional step takes the hex file and creates a binary image with a header describing each memory region's offset and size.