TMS320F28069M: .TI.ramfunc changes for Motorware examples

Just as a follow-up to this, I've done everything I can find to modify these, namely: 

1. replaced #pragma CODE_SECTION with __attribute__((ramfunc))

2. Added memory map section, as below: 

It sounds like you've done everything you're supposed to to use the ramfunc attribute.

1. Does this issue occur both when you have the emulator connected and when you're running standalone?

2. Are you getting any build/linker warnings?

Thanks,
Whitney

Hi Whitney,

Alas, without the emulator connected it doesn't function at all: might be the same problem or could be something else (still tracking this one down). No build/linker warnings: its all clean. 

One thought I had was about the implementation of .binit copy functions: do I need to write this, or should it be included somewhere in the project? Just thinking because our project is an upgrade of a now rather-old project, something may be missing which would normally have been constructed by default. 

Further testing last night pretty much confirmed the failure: IllegalISR() being thrown on the first ramfunc it comes to. 

Mat

One more thought: my application uses the CLA, but the handling is still performed in the old-manner, aka:


Cla1Prog : LOAD = FLASHA_B,
RUN = CLA_PROG,
LOAD_START(_Cla1funcsLoadStart),
LOAD_END(_Cla1funcsLoadEnd),
LOAD_SIZE(_Cla1funcsLoadSize),
RUN_START(_Cla1funcsRunStart),
PAGE = 0

would this cause incompability with binit routines?

Very lost here!

Having done some more reading/thinking on this subject, it's raised more questions than answers.

Because the ESTOP is occuring on the mainISR call, this might be related to the assignment/copying of the interrupt vector table between Flash and RAM. Reading spra958l, it states "At power-up, all interrupt vectors must be located in non-volatile memory (i.e., flash), but copied to the PIEVECT RAM as part of the device initialization procedure in your code". Motorware doesn't do this: instead it initialises the Interrupt Vector Table directly into memory location 0x0000 0D00 as part of the _PIE_Obj_ structure: with vectors being directly written into 0x0000 0D00 tables in code. The question then becomes:

1. Why is spra958l so specific about saying they must be located in flash then copied to RAM at runtime?
2. Using the standard Motorware ISR vector allocation HAL_initIntVectorTable(), which function address is assigned to the vector: the one in Flash or .binit's copy in RAM?

Could really do with some clarification here: the more I read the more confusing the subject becomes!

Is the mainISR the only function that is throwing the IllegalISR though? I thought maybe some of the other ramfuncs like usDelay or flash configuration functions may have had the issue as well. Is that not the case?

I think spra958l is assuming that most applications will put their vector table into a constant table that gets stored in flash instead of plugging them a few at a time in code. Assuming you want all of your ISRs to run from RAM for the best performance, the table in flash would be full of RAM addresses that will be copied into the 0xD00 table. The way MotorWare labs do it isn't necessarily wrong though. Also, the code gen tools know that because you put different load and run addresses in the cmd file that it should use the run (RAM) address when you do &mainISR in the code. You can put a breakpoint in HAL_initIntVectorTable() to be sure though.

I did some experiments trying to update a MotorWare lab to use the ramfunc attribute and I can't seem to reproduce this. The copy appears to be getting generated as expected. I'll message the code gen team and see if they any ideas.

Whitney

Thanks for the reply: all very valid questions.

Its definitely the mainISR which is causing the current problems. I've just run a build which has all the copy-to-ram functions enabled except for the mainISR at it runs OK. However, with mainISR set to copy-to-RAM it throws up the moment the ISR is enabled - with the stack backtrace pointing at mainISR entry point. 

Running the debugger through HAL_initVectorTable() shows mainISR address at 0x85b7, which correlates with the map file (and is a RAM location, not Flash). 

So the possibilties from here are: 

1. function isn't actually being copied to its RAM-linked location (doubtful).

2. Something else is throwing the CPU when accessing mainISR, but only with ramfuncs enabled (likely) 

Is there any rules about needing to load this functions into lower-64k regions, or specifics about PROGRAM MEMORY vs DATA MEMORY (I'm loading into program)? 

I haven't had chance to run an unmodified Motorware example today, tomorrows job. The linker file has been modified quite substantially for my application - to support CLA/CAN so memory has been messed around with. If there are any salient rules I've missed, this'd certainly do it. I'll copy my linker file below for completeness, if you can spot anything? 

MEMORY
{
PAGE 0 :   /* Program Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
   RAML0_1     	   : origin = 0x008000, length = 0x000C00     /* on-chip RAM block L0 and L1 */
   CLA_PROG        : origin = 0x009000, length = 0x001000
   RAM_FOR_FUNCS   : origin = 0x00A000, length = 0x002000     /* on-chip RAM block L4 */
// INSTASPIN       : origin = 0x013800, length = 0x000800

   OTP             : origin = 0x3D7800, length = 0x000400     /* on-chip OTP */
   FLASHH          : origin = 0x3D8000, length = 0x004000     /* on-chip FLASH */
   FLASHG          : origin = 0x3DC000, length = 0x004000     /* on-chip FLASH */
   FLASHF          : origin = 0x3E0000, length = 0x004000     /* on-chip FLASH */
   FLASHE          : origin = 0x3E4000, length = 0x004000     /* on-chip FLASH */
   FLASHD          : origin = 0x3E8000, length = 0x004000     /* on-chip FLASH */
   FLASHC          : origin = 0x3EC000, length = 0x004000     /* on-chip FLASH */
   FLASHA_B        : origin = 0x3F0000, length = 0x007F80     /* on-chip FLASH */
   CSM_RSVD        : origin = 0x3F7F80, length = 0x000076     /* Part of FLASHA.  Program with all 0x0000 when CSM is in use. */
   BEGIN           : origin = 0x3F7FF6, length = 0x000002     /* Part of FLASHA.  Used for "boot to Flash" bootloader mode. */
   CSM_PWL_P0      : origin = 0x3F7FF8, length = 0x000008     /* Part of FLASHA.  CSM password locations in FLASHA */

   FPUTABLES       : origin = 0x3FD590, length = 0x0006A0	 /* FPU Tables in Boot ROM */
   IQTABLES        : origin = 0x3FDC30, length = 0x000B50    /* IQ Math Tables in Boot ROM */
   IQTABLES2       : origin = 0x3FE780, length = 0x00008C    /* IQ Math Tables in Boot ROM */
   IQTABLES3       : origin = 0x3FE80C, length = 0x0000AA	 /* IQ Math Tables in Boot ROM */

   ROM             : origin = 0x3FF3B0, length = 0x000C10     /* Boot ROM */
   RESET           : origin = 0x3FFFC0, length = 0x000002     /* part of boot ROM  */
   VECTORS         : origin = 0x3FFFC2, length = 0x00003E     /* part of boot ROM  */

PAGE 1 :   /* Data Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
           /* Registers remain on PAGE1                                                  */

   BOOT_RSVD       : origin = 0x000000, length = 0x000050     /* Part of M0, BOOT rom will use this for stack */
   RAMM0           : origin = 0x000050, length = 0x0003B0     /* on-chip RAM block M0 */
   RAMM1           : origin = 0x000400, length = 0x000400     /* on-chip RAM block M1 */

   CLA1            : origin = 0x001400, length = 0x000080     /* CLA Registers */
   CLA1_MSGRAMLOW  : origin = 0x001480, length = 0x000080     /* CLA to CPU */
   CLA1_MSGRAMHIGH : origin = 0x001500, length = 0x000080     /* CPU to CLA */

   ECANA           : origin = 0x006000, length = 0x000040     /* eCAN-A Control and Status Registers */
   ECANA_LAM       : origin = 0x006040, length = 0x000040     /* eCAN-A Local Acceptance Masks */
   ECANA_MOTS      : origin = 0x006080, length = 0x000040     /* eCAN-A Message Object Time Stamps */
   ECANA_MOTO      : origin = 0x0060C0, length = 0x000040     /* eCAN-A Object Time-Out Registers */
   ECANA_MBOX      : origin = 0x006100, length = 0x000100     /* eCAN-A Milboxes */

   CLARAM2         : origin = 0x008000, length = 0x000800
   CLARAM0         : origin = 0x008800, length = 0x000400
   CLARAM1         : origin = 0x008C00, length = 0x000400

   RAML4           : origin = 0x00A000, length = 0x002000     /* on-chip RAM block L4 */
   RAML5           : origin = 0x00C000, length = 0x002000     /* on-chip RAM block L5 */
   RAML6           : origin = 0x00E000, length = 0x002000     /* on-chip RAM block L6 */
   RAML7           : origin = 0x010000, length = 0x002000     /* on-chip RAM block L7 */
   RAML8           : origin = 0x012000, length = 0x001800     /* on-chip RAM block L8. From 0x13800 to 0x14000 is reserved for InstaSPIN */
   USB_RAM         : origin = 0x040000, length = 0x000800     /* USB RAM		  */
}

SECTIONS
{

   /* Allocate program areas: */
   .binit			   : > FLASHA_B,   PAGE = 0
   .cinit              : > FLASHA_B,   PAGE = 0
   .pinit              : > FLASHA_B,   PAGE = 0
   .text               : > FLASHA_B,   PAGE = 0
   codestart           : > BEGIN,      PAGE = 0
   .TI.ramfunc         : LOAD = FLASHA_B,
                         RUN = RAML0_1,
                         TABLE(BINIT),
                         PAGE = 0, ALIGN(4)

   csmpasswds          : > CSM_PWL_P0, PAGE = 0
   csm_rsvd            : > CSM_RSVD,   PAGE = 0

   /* Allocate uninitalized data sections: */
   .stack              : > RAMM0,    PAGE = 1
   .ebss               : > RAML4,    PAGE = 1
   .esysmem            : > RAML4,    PAGE = 1

   /* Initalized sections to go in Flash */
   /* For SDFlash to program these, they must be allocated to page 0 */
   .econst             : > FLASHA_B,   PAGE = 0
   .switch             : > FLASHA_B,   PAGE = 0

   /* Allocate IQ math areas: */
   IQmath              : > FLASHA_B,   PAGE = 0            /* Math Code */
   IQmathTables        : > IQTABLES,   PAGE = 0, TYPE = NOLOAD
   
   Cla1RegsFile    : > CLA1,        PAGE = 1
   Cla1Prog        : LOAD = FLASHA_B,
                     RUN = CLA_PROG,
                     //TABLE(BINIT)
                     LOAD_START(_Cla1funcsLoadStart),
                     LOAD_END(_Cla1funcsLoadEnd),
                     LOAD_SIZE(_Cla1funcsLoadSize),
                     RUN_START(_Cla1funcsRunStart),
                     PAGE = 0

   Cla1ToCpuMsgRAM  : > CLA1_MSGRAMLOW,   PAGE = 1
   CpuToCla1MsgRAM  : > CLA1_MSGRAMHIGH,  PAGE = 1
   Cla1DataRam0		: > CLARAM0,		  PAGE = 1
   Cla1DataRam1		: > CLARAM1,		  PAGE = 1
   Cla1DataRam2		: > CLARAM2,		  PAGE = 1

   CLAscratch       :
                     { *.obj(CLAscratch)
                     . += CLA_SCRATCHPAD_SIZE;
                     *.obj(CLAscratch_end) } > CLARAM0,
					 PAGE = 1

   /*** Peripheral Frame 1 Register Structures ***/
   ECanaRegsFile     : > ECANA,       PAGE = 1
   ECanaLAMRegsFile  : > ECANA_LAM,   PAGE = 1
   ECanaMboxesFile   : > ECANA_MBOX,  PAGE = 1
   ECanaMOTSRegsFile : > ECANA_MOTS,  PAGE = 1
   ECanaMOTORegsFile : > ECANA_MOTO,  PAGE = 1

   /* Allocate FPU math areas: */
   FPUmathTables       : > FPUTABLES,  PAGE = 0, TYPE = NOLOAD
   
   DMARAML5	           : > RAML5,      PAGE = 1
   DMARAML6	           : > RAML6,      PAGE = 1
   DMARAML7	           : > RAML7,      PAGE = 1
   DMARAML8	           : > RAML8,      PAGE = 1   

 
   /* .reset is a standard section used by the compiler.  It contains the */
   /* the address of the start of _c_int00 for C Code.  */
   /* When using the boot ROM this section and the CPU vector */
   /* table is not needed.  Thus the default type is set here to  */
   /* DSECT  */
   .reset              : > RESET,      PAGE = 0, TYPE = DSECT
   vectors             : > VECTORS,    PAGE = 0, TYPE = DSECT

}