TMS320F28069M: flash linker cmd file

Hi Dave,

Please refer to this link for F2806x devices:

https://e2e.ti.com/support/microcontrollers/c2000-microcontrollers-group/c2000/f/c2000-microcontrollers-forum/758797/faq-f05-flash-how-do-i-convert-a-ram-based-project-to-a-flash-based-project

For Linker Command File, please take a look at this file in C2000Ware SDK.

C:/ti/c2000/C2000Ware_4_03_00_00/device_support/f2806x/common/cmd/F28069.cmd

Regards, Santosh

Thanks Santosh! I'll check these out.

Best Regards,

Dave

Hi Santosh,

I have another somewhat related question. I can't add memCopy.c to my project. I've tried linking to it and copying it. I just get a pop-up box saying 

" Could not link: memCopy.c" I've had no trouble adding other files to the project. Why this one?

Thanks,

Dave

Hi Dave,

does this file came from C2000Ware or it is your custom file? We should be able to add the file without any issue? Can you share the screen-shot when you are adding a linked fie? 

Regards, Santosh

Hi Santosh,

The file is from C:\ti\motorware\motorware_1_01_00_18\sw\modules\memCopy\src

Here's the screenshot:

Thanks,

Dave

Hi Dave,

I am not sure what is special about that file. The file is physically available on disk, right? It is not a linked file itself, right?

I am not familiar with MotorWare SDK. I do not think it is being supported any more. I am forwarding the thread to engineer who is familiar with MotorWare SDK.

Regards, Santosh

Not being supported? Does that mean InstaSpin is not being supported? Is TI planning on obsoleting InstaSpin?

I don't think there is anything special about that file. It's physically available on disk, and is not a linked file itself. I can't link to memCopy, no matter where I source it from. I can literally copy and paste it into my project folder, and CCS won't add it to the project. If I change the name of the file to memoCopy.c, or memoryCopy.c, it will add the file, but that ends up in other linker issues.

Thanks Yanming.

He had me worried, saying that "I do not think it is being supported any more."

Thank you for directing me to Lab 10a. I'll check that out.

Best Regards,

Dave

Hi Yanming,

I looked at Lab 10a. It doesn't seem to have anything in particular to do with running from Flash. I can't even find the word "Flash" in the lab.

It's more concerned with Space Vector Over Modulation, as the title suggests.

Are you sure you meant Lab 10a?

Thanks,

Dave

Hi Yanming & Santosh,

I tried "Build Configurations"->"Set Active"->"Flash". I still don't have a board that runs my firmware as an independent unit, without the debugger plugged in.

Evidently 2 boot mode pins GPIO37 (pin 70 on the micro I'm using), and GPIO34 (pin 68) have to be tied high. I did not do this in hardware. Is there a way for these 2 pins to be pulled up internally, by default? Otherwise, I'll need another board spin.

Thanks,

Dave

Hi Yanming & Santosh,

Ok - it looks like, according to the Tech Reference for the TMS320x2806x, that: "For pins that can function as ePWM output pins, the internal pullup
resistors are disabled by default. All other GPIO-capable pins have the pullup enabled by default." So GPIO34 & GPIO37 should both be tied high by default. Does that mean I don't have to pull them up with a resistor? Or could this "default" be put into effect too late to be evaluated properly as boot mode pins (i.e. after power on reset)?

Thanks,

Dave

Dave Reagan said:

So GPIO34 & GPIO37 should both be tied high by default. Does that mean I don't have to pull them up with a resistor?

It's better to add a pullup resistor for these two pins to set the boot mode to "flash". Yes, there are an internal pullup on these two pins which will set the boot mode to "flash mode" if you leave these two pin to float without connecting any signals to these two pins.

Hi Yanming,

I installed the pull-up resistors. The board now boots from FLASH (big step in the right direction), but I can no longer communicate with the LCD.

I suspect that maybe raising the Optimizations to level 2 (I'd always used 0 when running from the debugger) might be responsible.

I'm using SCI (port B) to communicate with the LCD. This worked when running from the debugger.

Any suggestions?

Thanks,

Dave

Here's the latest. It does not boot completely independently of the debugger.

If I program the device, then shut down the IDE, but leave the debugger (the XDS110) plugged in, I can remove power, then re-apply power, and the board spins a motor at a default rpm. It will not, however, communicate with the LCD, so I can't change the speed. If I remove the debugger, the board keeps on spinning the motor. If I plug the debugger back in, same thing - keeps spinning the motor, but won't talk to the LCD.

If I remove power from the board, and unplug the debugger, reintroduce power to the board, then re-attach the debugger, the motor starts spinning, and I can change the speed via the LCD. At this point, if I unplug the debugger, the board does not lose any of these capabilities.

How does having the debugger plugged into the board allow it to boot from FLASH?

And why does attaching the XDS110 long after power-up allow the communications to work, while just leaving the XDS110 plugged while powering up does not?

Are you working on your own board or a TI EM kit?

It's my own board.

Hi Yanming,

On my Board:

TMS, TDI, TDO, and GPIO34 are all tied High, through 3.3k resistors.

TCK is tied Low, through a 3.3k resistor.

VREGENZn is tied directly to ground.

XRSn is pulled high through a 2.2k resistor.

TRSTn has a 1k pull-up and a 2.7k pull-down resistor.

Does this seem like a reasonable setup? Or could one or more of these be wrong?

On the TI schematic for the F28069U Controller Card:

TMS, TCK, and TDI are apparently not pulled in either direction.

TDO and GPIO34 are pulled High through two 820 ohm resistors (when in Boot Mode), and Low through 3.3k ohm resistors.

VREGENZn is tied directly to ground.

XRSn is pulled high through a 2.2k resistor.

TRSTn is pulled Low through a 2.2k pull-down resistor.

Should I just copy all of these, or could I get way with just changing 1 or 2 of my pullups/pulldowns?

Thanks,

Dave

Okay - I tried emulating the F28069U Controller Card exactly, regarding the above pullups/pulldowns.

The motor spins, but only at the default setting of 1,000 rpm. I can't change anything via the LCD.

If I restore the pullup at TRSTn, then I can talk to the board via the LCD, but only if it starts up without the debugger, and then the debugger (XDS110) is plugged in later. So it seems like it wants to see some transition provided by plugging the debugger in.

Any ideas what might be going on?

Thanks,

Dave

What could be wrong here? Why would running from FLASH perform some parts of the code and not others?

It spins the motor, but won't acknowledge messages coming in via the UART.

What am I missing?

Dave,

Can you comment the clock source you are using for the C2000?  Are you using the internal 0-pin oscillator, or switching to an external X-tal/clock source? 

I'm wondering if what we are seeing when you plug in the debugger is related to TCK signal vs TRSTn.  TRSTn is expected to remain low during normal operations, I would not expect a transition on that pin to correct things. 

TCK, on the other hand uses the same GPIO38 as a XCLKIN option.  If you are using XCLKIN from GPIO38 there may be some clock issue at play that the JTAG fixes when it gets plugged in.

Alternatively, if CCS is connected/debugging does everything work correctly code wise, and only if we try and run standalone that you see the issue? 

We support an emulation boot mode to mimic the standalone modes using EMU_BOOT/EMU_KEY locations in memory that might prove useful here, i.e. emulate a boot from flash with CSS connected and see if things still work.  If you confirm that when actively debugging(not just plugged in, but running things from CCS) then that might be the best place to continue your debug.

Best,

Matthew

Hi Matthew,

I'm using a 20MHz crystal oscillator connected to X1 & X2 (pins 60 & 59, respectively) on the TMS320F28069M. This is bumped up internally to a 90 MHz clock. GPIO38 is currently being used only for TCK.

Yes, everything works correctly when the debugger is plugged in, and CCS is controlling it. These issues only exist when trying to run stand-alone. Oddly enough, when the pull-up resistor for TRSTn is present, it also works correctly without CCS, as long as you start it up, and then plug in the debugger.

How do I use EMU_BOOT/EMU_KEY? Is there a document or a tutorial to guide me?

Thanks for your help.

Best Regards,

Dave

Hi Matthew,

After looking at the Technical Reference Manual:

EMU_KEY is set to 0x55AA, and EMU_BMODE is set to 0x0003. This configures the Boot Mode to GET_BOOT, which means get the mode from OTP_KEY/OTP_BMODE.

OTP_KEY (at address 0x3D7BFB) is set to 0xFFFF, which I don't know how to interpret.

It says in the manual that "if OTP_KEY == 0x005A, then check OTP_BMODE for the boot mode." But no other values of OTP_KEY are discussed.

Even if OTP_KEY were equal to 5A, none of the boot modes listed imply that there is an "Emulate FLASH" mode. It looks like it's the actual FLASH boot mode. (Note: I tried changing OTP_KEY to 005A, but was not allowed to edit it from the Memory Browser.)

I get the feeling that this is what I've been doing all along, whenever I've used CCS while having everything set up for a FLASH boot.

So, assuming that's the case, what information can I glean from running via CCS (everything runs as expected when using it)?

Can you give me some direction?

Thanks,

Dave

Dave,

Sorry for the delay, I was out yesterday.

I think that CCS might be "helping" us with some of its auto-load features that are useful for debugging, but less so for duplicating standalone.

There is a config for emu_boot to flash from the "scripts" menu item in CCS, this will set up the EMUBOOT and KEY.

Now, we need to disable the auto go to main on program load, if you go to "Tools->Debugger Options->Auto-load/run" it will bring up the yellow highlighted box below.  You need to un-check the run to main option I highlighted in red.

So now, after you load the code you'll want to execute a "Reset" which will take us to the BROM starting address.  Since debugger is connected, and we picked flash emu boot this should emulate the stand alone condition.  Once we "Run" we should see the same "bad" behavior you do wrt to the LCD not responding, etc.  At this point we can halt the code to see where it is at, and then track back from there.  You can set BP at main, etc to try and track down where things are going wrong.

If we don't see the bad behavior , I'll have to re-think what the issue could be since we should be identical more or less to the standalone mode.

Best,

Matthew

Hi Matthew,

I followed your instructions and have a debuggable system running from (virtual) FLASH!

It has the same problems as the FLASH version, and I can put in breakpoints.

I should be able to track this down now. Thanks so much for your help.

Best Regards,

Dave

Hi Matthew,

I'm still none the wiser regarding the root cause of this.

Being able to debug while running from FLASH was helpful, but for some reason it has stopped working. In any case, I still haven't locked down a reason for why the micro is not responding to messages delivered to its UART. I'm using SCIB, at a BAUD rate of 19.2k. 

In the main ISR I have the following code:

if(SCI_get_rxrdy_flag_il(halHandle->sciBHandle) != 0)
{ ...

}

and all the SCIB receive handling is done dependent on the state of the Rx Ready Flag.

I ran the firmware with the debugger in the Flash emulation mode, and without it.

During Flash emulation, and evidently when running stand-alone from Flash, Rx is never ready. When using the debugger in the traditional fashion, it acknowledges and handles most transmissions from the LCD.

I've compared the register values from running in both modes (debugging with & without Flash emulation), and the only difference I can discern is SCICTL2 has a value of 0x00C0 when the comm is not working, and a value of 0x00C1 when it is working. That is, it works when the RXBKINTENA bit is set.

Well... as far as I know, I'm not using the Rx Interrupt. Maybe it fires whether I'm explicitly using it or not - I'm not sure. But I'm polling from a timed interrupt to get the data.

Luckily, the method you described for emulating Flash operation worked long enough for me to make the register comparison.

Back when it was working, when I reset the CPU, it evidently just went to the starting point in code that would allow it to run from FLASH, without any fanfare, or messages saying where it had gone. Now when I go through the procedure of:

connecting to the target,

selecting the EMU Boot Mode Select script = EMU_BOOT_FLASH,

then unchecking the checkbox for Run to symbol "main" on a program load or restart,

then reset the CPU,

I get the following message on a new Tab:

I don't think it did this back when it was working.

After that, when I click the "Run" icon, the firmware behaves as though the firmware were running from the debugger, in the traditional manner (i.e. everything's fine, the comm works, etc...). I did get the Flash Emulation to work, both yesterday afternoon and a couple times this morning. I have no idea what changed, if anything. I certainly haven't changed the code. I may have inadvertently clicked on something, though. I don't know. I suppose anything can happen.

Thanks,

Dave

Oh yeah - you mentioned that "I think that CCS might be "helping" us with some of its auto-load features that are useful for debugging, but less so for duplicating standalone." Is there a way to determine which of these features is "helping," and maybe include them somehow in the program that's loaded to FLASH?

Thanks,

Dave

Dave,

In your first post, you show the "address outside of program code".  This address is in the Boot ROM, if you go to C:\ti\c2000\C2000Ware_4_03_00_00\libraries\boot_rom\f2806x\v1_1\rom_sources\Release you can load symbols from the release.out you see there.  This should allow CCS to show you where in the code you are getting stuck.

The difference in what we are doing is that before CCS was executing the C28x initialization code in boot ROM and then forcing a jump to main().  Now, we are relying on the flash boot flow itself to get us to main, and we are getting stuck somewhere.  That is what I had you disable.

If you have C2000Ware installed, I'd like for you to import the project located here C:\ti\c2000\C2000Ware_4_03_00_00\device_support\f2806x\examples\c28\flash_f28069

This project is built to run from flash/flash boot.  You will notice there is a .asm file included called "code_start_branch" I would also look a the .cmd file for the section labeled "codestart"

Can you see if this .asm is part of your project?  This will call the c_int00 function that sets things up when the flash entry point is called from the BROM before going to main()

Best,

Matthew

Hi Matthew,

I apologize for my ignorance, but I don't know what to do with the release.out from ...rom_sources that you mentioned. For one - how exactly do I load symbols from release.out? And if I do, how can this show me where I'm getting stuck? Do I load it simultaneously with the program I'm struggling with?

I also tried loading and running the flash_28069 example project you suggested, but I get a bunch of error messages.

CodeStartBranch.asm is included in my project. It does reference the c_int00 function a few times. But I'm not sure what's going on there...

Should I compare my .asm file and the one associated with the flash_28069 example project to see whether there are any errors?

There is also a line in F28069M.cmd as follows:

/* Uncomment this line to include file only for non-BIOS applications */
-l F2806x_Headers_nonBIOS.cmd

I uncommented it, as instructed, but can't seem to access it via the usual "Open Declaration". Should I explicitly include this file in my project, or at least update the File Search Path under Properties/C2000 Linker in Code Composer to include the folder where it is stored? Or does the "-l" directive take care of that?

Thanks for your help.

Best Regards,

Dave

Dave,

For the release.out, you can load symbols either before or after you load your main code(screenshot below).  Since it is ROM/symbols it won't overwrite anything in your code;

Can you attach or C/P the .cmd file you are using for your program so I can take a look?  I can verify if the load address match to what I'm expecting.  I'm npt sure why you can't load the example file, if you can C/P that error text from that attempt I can check that as well.

The additional .cmd file you are including is the information for the bitfields used in our header files.  If code is running on emulator, then this likely is not the issue.  I assume you are using motorware?  This is different than our controlSUITE, which uses that linker, if you are running motorware that has drivers vs the bitfields in our standard C2000Ware release.

Best,

Matthew

Hi Matthew,

I've attached the F28069M.cmd file. Had to add the ".txt" extension. Your website didn't want me attaching a ".cmd" file.

Here's a screenshot of the errors when compiling the FLASH-F28069 project:

Good to know that I don't need the bitfield info. I am using Motorware.

Thanks,

Dave

/*
//###########################################################################
//
// FILE:    F28069M.cmd
//
// TITLE:   Linker Command File For F28069M Device
//
//###########################################################################
// $TI Release: F2806x C/C++ Header Files and Peripheral Examples V135 $ 
// $Release Date: Sep 8, 2012 $ 
// $Copyright:
// Copyright (C) 2009-2022 Texas Instruments Incorporated - http://www.ti.com/
//
// 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.
// $
//###########################################################################
*/

/* ======================================================
// For Code Composer Studio V2.2 and later
// ---------------------------------------
// In addition to this memory linker command file,
// add the header linker command file directly to the project.
// The header linker command file is required to link the
// peripheral structures to the proper locations within
// the memory map.
//
// The header linker files are found in <base>\headers\cmd
//
// For BIOS applications add:      F2806x_Headers_BIOS.cmd
// For nonBIOS applications add:   F2806x_Headers_nonBIOS.cmd
========================================================= */

/* ======================================================
// For Code Composer Studio prior to V2.2
// --------------------------------------
// 1) Use one of the following -l statements to include the
// header linker command file in the project. The header linker
// file is required to link the peripheral structures to the proper
// locations within the memory map                                    */

/* Uncomment this line to include file only for non-BIOS applications */
-l F2806x_Headers_nonBIOS.cmd

/* Uncomment this line to include file only for BIOS applications */
/* -l F2806x_Headers_BIOS.cmd */

/* 2) In your project add the path to <base>\headers\cmd to the
   library search path under project->build options, linker tab,
   library search path (-i).
/*========================================================= */

/* Define the memory block start/length for the F2806x
   PAGE 0 will be used to organize program sections
   PAGE 1 will be used to organize data sections

   Notes:
         Memory blocks on F28069 are uniform (ie same
         physical memory) in both PAGE 0 and PAGE 1.
         That is the same memory region should not be
         defined for both PAGE 0 and PAGE 1.
         Doing so will result in corruption of program
         and/or data.

         Contiguous SARAM memory blocks can be combined
         if required to create a larger memory block.
*/

MEMORY
{
PAGE 0 :   /* Program Memory */
           /* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */
   RAML0       : origin = 0x008000, length = 0x000800     /* on-chip RAM block L0 */
   RAML1       : origin = 0x008800, length = 0x000400     /* on-chip RAM block L1 */
   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 */
   RAML2_3     : origin = 0x008C00, length = 0x001400     /* on-chip RAM block L2 */
   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 */
   USB_RAM     : origin = 0x040000, length = 0x000800     /* USB RAM		  */   
}

/* Allocate sections to memory blocks.
   Note:
         codestart user defined section in DSP28_CodeStartBranch.asm used to redirect code
                   execution when booting to flash
         ramfuncs  user defined section to store functions that will be copied from Flash into RAM
*/


SECTIONS
{

   /* Allocate program areas: */
   .cinit              : > FLASHA_B,   PAGE = 0
   .pinit              : > FLASHA_B,   PAGE = 0
   .text               : > FLASHA_B,   PAGE = 0
   codestart           : > BEGIN,      PAGE = 0
   ramfuncs            : LOAD = FLASHD,
                         RUN = RAML0,
                         LOAD_START(_RamfuncsLoadStart),
                         LOAD_END(_RamfuncsLoadEnd),
                         RUN_START(_RamfuncsRunStart),
                         PAGE = 0

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

   /* Allocate uninitalized data sections: */
   .stack              : > RAMM0,      PAGE = 1
   .ebss               : > RAML2_3,    PAGE = 1
   .esysmem            : > RAML2_3,    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
   
   /* 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   

  /* Uncomment the section below if calling the IQNexp() or IQexp()
      functions from the IQMath.lib library in order to utilize the
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
   /*
   IQmathTables2    : > IQTABLES2, PAGE = 0, TYPE = NOLOAD
   {

              IQmath.lib<IQNexpTable.obj> (IQmathTablesRam)

   }
   */
   /* Uncomment the section below if calling the IQNasin() or IQasin()
      functions from the IQMath.lib library in order to utilize the
      relevant IQ Math table in Boot ROM (This saves space and Boot ROM
      is 1 wait-state). If this section is not uncommented, IQmathTables2
      will be loaded into other memory (SARAM, Flash, etc.) and will take
      up space, but 0 wait-state is possible.
   */
   /*
   IQmathTables3    : > IQTABLES3, PAGE = 0, TYPE = NOLOAD
   {

              IQmath.lib<IQNasinTable.obj> (IQmathTablesRam)

   }
   */

   /* .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

}

/*
//===========================================================================
// End of file.
//===========================================================================
*/

Hi Matthew,

I've loaded symbols for TMS320x2806x_boot_rom_gold_release.out.

When my code is first loaded, the tab below appears:

As soon as I load symbols, I see the following:

Same location, looks like the same assembler code, but the label "main():" is missing.

Then, when I attempt to emulate a boot from FLASH,

upon Reset, I get this:

Evidently trying to enable the watchdog (not sure I'd want that just yet...), but can't find a source file at C:\work\... which is a folder that doesn't exist on my machine.

Let me know what you think.

Thanks,

Dave

It appears we have a hardcoded path in our ROM lib builds.  I'm going to reach out to you privately via the E2E friend request, we may need to take this off-forum for a bit to see if we can help you a bit more efficiently.  Please look out for a notification in the upper right corner of the E2E window via the dialog bubble.

Best,

Matthew

Sounds like we're onto something!

Hi Matt,

I put the project in the TI drive. Hopefully you've got it.

Thanks,

Dave

Yes, I've got it.  Will let you know what I find out.

Best,

Matthew

Dave,

When you are able to duplicate the issue using EMU_BOOT, if you load, reset, and then run to main does that work?  If this does work, can you give some more detail on where the code fails for you?

I've been able to load/run/etc here on my LaunchPad, and I get to main and then I continue running.  I don't have a motor or LCD display hooked up, so I can't confirm if that is the issue.  I don't see the code go into the weeds, it is still running and I see it return to your main code, etc.

I don't think this is a un-initialized memory issue; I cleared out all the RAM before loading the .out and I don't see the program load writing to RAM, which is important for stand alone type projects.

Best,

Matthew

Hi Matthew,

Unfortunately, I am not able to duplicate the issue (motor runs, but no communication), using EMU_BOOT. The only time I see this is when running completely stand-alone. Unless by "issue" you mean the fact that I can't emulate stand-alone while the debugger is plugged in & CCS is controlling things. In that case, I tried using EMU_BOOT, then going through the whole emulation setup procedure (load program, EMU_BOOT_FLASH, Reset CPU) again, but with the "Auto Run Options" set to "Run to symbol 'main' " and with the checkbox "On a program load or restart" selected. The program runs as intended (motor spins, and system responds to changes in motor speed communicated by LCD). That is, it runs exactly the same as if I had left "On a program load or restart" unchecked.

When running stand-alone, it does not appear to be going into the weeds, in the way that I would normally think of it, since it continues spinning the motor. But for some reason, it's ignoring serial messages sent to it by the LCD.

Thanks,

Dave

Dave,

I misunderstood the previous post, we should be able to emulate/replicate what you are seeing in standalone unless this was a HW issue, i.e. the boot pins aren't driven correctly.  Reading through the post, I think we've already checked that so that shouldn't be the issue.

One last thing to try in CCS, when you are connected to target click "Tools" from the top ribbon and then select "GEL Files"

Go ahead and invoke EMU Boot mode as before, then in the new dialogue box from above action, I want you to right click this and "Remove" the GEL file.  This will remove any more "On file load" "on reset" auto actions.

Then repeat the same steps as before, load the .out, reset, and run.  Do we see things working as expected, or failing as you see in standalone?

Best,
Matthew

That must have been it! It's running in the same fashion as stand-alone.

Thanks,

Dave

Hi Matthew,

Well, I'm really in a fix now. I got rid of the GEL file and ran the code as before (EMU_BOOT_FLASH, reset, run...). I found that, if I put a breakpoint in the right location, and then run from there, I could often get the Motor Control Board to pick up communications from the LCD. In free run, nothing happens. For some reason (escapes me now), I decided to stop the program, and reload / restart it. Now when I try to run it again, it allows me to connect and load the program, but the resume button is grayed out. There are no scripts available, familiar tools are gone. The only thing I'm allowed to do, evidently, is terminate. I've tried that, and when I load it again, I get the same results. I even tried closing CCS, cycling power, and starting over completely - same thing. What could be going on here? Seems like everything that could possibly go wrong... is.

Thanks,

Dave

Hi Matthew,

Ok - I deleted all the breakpoints, and everything appears to be back to normal. Am I only allowed like one breakpoint in this mode?

Thanks,

Dave

Dave,

Since the code is in Flash, we have to use the HW breakpoints that are part of the MCU.  We only have 2 of these units, and if you are "running to main" that will use one of them.  However, you can selectively add/remove them as you break to keep 1 free.

That's good news that we can replicate.  BTW, the GEL file is located here: C:\ti\ccs1000\ccs\ccs_base\emulation\gel if you want to reload it, or perhaps more importantly look through it. 

There is one thing that jumps out at me:  The Unlock_CSM() function call.  Essentially for an unlocked device you just read the password locations to unlock things.  If your code is never doing this then a data read into secure space could return 0x0000(a function call is OK).

OnReset(int nErrorCode)
{
    if (GEL_IsInRealtimeMode())   /* If in real-time-mode */
    {
    }
    else    /* Put device in C28x mode */
    {
         C28x_Mode();
    }
    Unlock_CSM();
    Device_Cal();
    CLA_Clock_Enable();             /* Enable CLA clock - allows to debugger to set CLA breakpoints after reset */
    
//  EMU_BOOT_SARAM();               /* Set EMU Boot Variables - Boot to SARAM */
//  EMU_BOOT_FLASH();               /* Set EMU Boot Variables - Boot to flash */
}

Best,

Matthew