How to Boot Entire Program from FLASH and Execute in RAM

Greg,

See Appnote SPRA958.  The title is running from flash, but it also explains how to copy to and run code from RAM.

http://www.ti.com/mcu/docs/litabsmultiplefilelist.tsp?sectionId=96&tabId=1502&literatureNumber=spra958k&docCategoryId=1&familyId=1414

>> Using the JTAG and the debugger to progam FLASH and then Run is the same as cycling power with BOOT pins

After flashing the device, the CCS default behavior is to do a RESTART, which is different from a RESET.  RESTART sets the PC to the software entry point of your program, which is usually _c_int00.  Entry point is just a CCS thing.  It has no meaning to the C28x itself.  If you did a reset in CCS and then hit run, that is pretty much the same as doing a hardware reset (although not exactly the same.  I think for a CCS reset, CCS simply tries to set all the registers to their reset default.  CCS reset does not actually do a hardware reset).

>> And finally I can not get InitFlash to execute correctly

On your InitFlash() issue, I don't think you have the function copied to RAM properly.  I can see in the screen shot you sent that the diassembly and op-codes are not correct.  For example, the first instruction in the C-source is EALLOW which is op-code 0x7622, but your diassembly window is showing an ADDL with opcode 0x07FA.  Also, notice it is showing multiplies (MPYB), bit test (TBIT), XOR, etc. for C-source code that is strict assignment.  Makes no sense.  I theorize that the RAM contents are garbage, and the function has not been copied correctly from flash.

Good luck and Regards,

David

Yes - on the FlashInit problem I found that I was giving the copying function the wrong addresses (changing from MemCopy to memcpy and did not complete teh argument shuffling that this requires.)

And I am running from flash about 30%-45% slower than when running from RAM - using CCS.  (I do the Load Symbols, Reset, and Go Main and find each of, respectively, begin, code start branch, cint00, and Main; then I run, but from CCS.)  But when I disconnect CCS from the controlCARD, and cycle power, very different execution - like 50kHz processes are running at 100Hz - toggling GPIOs shown on scope - if they are even the same processes ...

So, yes, as far as goes the use of CCS and emultaor/JTAG to load/boot and run from Flash, that works but not when cycling power (We use Spectrum Traveler JTAG, but I use the TI supplied JTAG just for power - SO I CAN'T DISCONNECT THIS IN MY ATTEMPT TO BOOT TO FLASH DIRECTLY WITH NO CCS). 

In order to Run From RAM, 95% of all examples show running from FLASH everything but FlashInit - yet we will run everything from RAM.  Applying the FlashInit example to anything and everything that we wish to run from RAM would require that every function be preceded by a distinct CODE SECTION pragma and the linker command file have distinct LOAD and RUN directives for each function - OR AFTER MULLING OVER THE RESULTS FROM FOLLOWING THAT EXAMPLE one would probably devise a more streamlined approach based on that ... just surprised there is no widely publicized/trained -for example of loading MANY from FLASG and running them from RAM.

Do you know about "spraau8.pdf" ?

Now on to the GPIOs to boot to FLASH ... a F28335 data sheet says that the four are pulled high ... so what affect does this have on a custom board where the GPIOs are floating and what affect on a controlCARD where there are four micro DIP switches plus four columns of three posts each for jumpering to ground ?

THANK YOU, DAVID, FOR YOUR THOROUGH ASSISTANCE !!!  (I look forward to another quick response.)

Greg,

I wasn't familiar with spraau8.  I took a quick look.  It is just copying the code section very early in the initialization process, which allows the flash wait-states to be setup early and hence will speed up the initialization process.  This might be needed in applications that have very fast startup requirements.  In normal circumstances, you can do this from C, which is what is described in SPRA958.

If you really want to run EVERYTHING from RAM, you could just setup your linker .cmd file so that the .text sections from all of your source files are setup to load to flash and run from RAM.  You'd follow the same procedure as is in SPRA958, but the .text section would be the section you'd be copying.  This could get a little tricky because I believe the _c_int00 routine in the runtime support library (that runs before main()) is also in the .text section.  So, you may need to specify the source files in the linker .cmd whose .text sections you want to copy.  Check the C2000 assembly language tools user's guide, SPRU513.  You would form a next section, call it .text1, that is comprised of the .text sections from the source files you want to copy to RAM.  It will look something like this:

.text1: LOAD=FLASH, PAGE=0
           RUN=RAM, PAGE=1
{
   file1.obj(.text)
   file2.obj(.text)
    ...
   fileN.obj(.text)
}
LOAD_START(_text1_loadstart),
LOAD_SIZE(_text1_loadsize),
RUN_START(_text1_runstart)

Then use memory copy to copy the entire .text1 section to RAM.

---------

I think the GPIO pullups are active on F28335 by default.  So, the device will boot in whatever boot mode this corresponds to unless you design your board to pull the needed pins the other way.

Not sure about the problem you're saying where when you run without CCS frequencies are different.  Sounds like there is something that your code is not initializing correctly, but CCS is initializing it for you (the CCS .gel file can do this.  Check the .gel file you are using).  My suggestion is to work with the examples in SPRA958.  This is sound code, and correctly gets basic stuff setup.  You can modify the F28335_nonBIOS_flash example so that all the code runs from RAM.  Once you get that down, you can move to your own code.  The SPRA958 examples output a 2 kHz PWM on ePWM1 pin, so you can check proper operation on your scope.

- David

spraau8 does not just copy a single code section very early - that's what SPRA958 describes (although yes spraau8 does its copying before getting to c_int00, earlier than SPRA958, which is after c_int00).  spraau8 copies all code and data sections so that everything after Main entry point is executed IN RAM.

I think we are talking about the same things though except that there is no speed-up implemented through FLASH wait state minimization in spraau8.  That's what SPRA958 is doing - loading JUST InitFlash into RAM so that InitFlash can manipulate FLASH's wait states before entering continuing with the rest of the program - all the functions of which are then executed IN FLASH.  spraau8 does mention that application code start-up is slightly delayed by loading all of a program into RAM from FLASH, but since it implements it must take less time than doing something effectively the same via C/C++ and memcpy. 

I like how you created .text1 from specific files in .text, all files while avoiding omitting c_int00.  But that still leaves out .pinit (which I definitely needed because to carefully control initializaiton sequence of clocks, sysctrl, GPIO set-up, etc.,  I initialize instances of objects defining these operations by listing them in a specific order, globally ahead of main, and it leaves out .cinit, .const, etc.  Of course the same load, run linker command file definition can be included for those sections and run through a memcpy.  Note that apraau8 copied entire sections, identified by section name, so I don't think c_int00 is a problem.

And best of all, I am runnign at full speed - after a few fits and starts - from RAM, after booting to FLASH, loading FLASH to RAM (really pretty darn quick for a relatively large C++ program), albeit while using CCS - I still can't get it to boot up with just a power cycle.

Further help with that would be appreciated but of course requires detailed info on the TI cointrolCARD I am using.  Please call if you have a chance and I will make it as painless as possible.  Trey German has my email address and phone number.  In the mean time thanks for the answer !

Greg,

>> Note that apraau8 copied entire sections, identified by section name, so I don't think c_int00 is a problem.

Spraau8 copies the .text section before _c_int00 is run.  So, _c_int00 is run from RAM which is where the linker .cmd file is setup to have it run.  If you copy .text after _c_int00 is run from flash, then you cannot have _c_int00 setup in the linker command file to load to flash but run from RAM.  _c_int00 must be linked to load and run from flash.  That is why I had to tip-toe around the .text section for _c_int00.

On your startup problem when not using CCS, you need to step the code from a reset using CCS and see where you end up.  I suggest flashing the example code from SPRA958.  If you are running on the Experimenter's Kit (basic, barebones docking kit) you need take no special precautions.  If you have some other docking station, say some motor control board or something, then be careful that the example code blinks a GPIO (LED on experimenter's kit) and also outputs PWM on ePWM1 pin.  You may need to modify the gpio.c file to just not output anything on those pins so as not to cause any contention on your board.  Once flashed, reset the device in CCS, and then step the code.  It will take about 60 steps to get through the bootloader (keep stepping!!!).  Eventually, you should end up at the CodeStartBranch.asm file.  This will tell you that the bootmode pins are setup correctly.  If you get that far, then the example code should run from a power cycle without CCS.

Regards,

David

David,

Thanks again.  I should have provided more info on my boot to flash problem.  I have stepped through to code branch, section_copy (an additional asm file resulting from following the spraau8 approach), c_int00, etc., as described in the various documents and training material, all with success, after Load Symbols, and Reset, and I follow it with Go Main to get to Main.  So, in accord with all these documents I should be good to go.  But I am not. 

And I think it has something to do with defining some objects globally - in order to control the initialization order, the C++ constructors are executed in the order that these objects' definitions appear.  They are defined in the file containing main, ahead of main.  When not loading flash (when using a strictly RAM configuration), if I put a break point at one of the lines containing a definition and do a restart or a fresh load execution breaks at the  instantiation.  Stepping from there eventually gets me to Main and I can execute from there.  These instantiations set up GPIOs etc., which are needed for proper application execution.  Using FLASH these definitions are not executed.  SO I need to somehow instead of transferring from c_int00 to Main, I need to have these instantiations executed prior to Main.

The .pinit section involves construction of global (static ?) objects so I thought that since I include that section in the linker command file and by copying it back to RAM my problem should not have occurred.  But the _sti_ and ___ct__ symbols have addresses that seem not to cincide with the .pinit section.  Can you send me your email address so that I can send you my map file ? (via conversations ...)

00009ca8 ___sti___11_ps_main_cpp_main 

(this is the symbol for the start of the instance definition hilited below)

00009b95 ___ct__Q2_2PS12CMcBsp_IntfcFv 

(maybe these are the symbols for the instance declaration appearing in the individual hpp files ...)

0000a2c6 ___ct__Q2_2PS5CGpioFv

00009528 ___ct__Q2_2PS5CSciAFv

0000959f ___ct__Q2_2PS5CSciBFv

0000961a ___ct__Q2_2PS5CSciCFv

000084b0 ___ct__Q2_2PS6CAdcIfFv

000097bf ___ct__Q2_2PS7CGpioIfFv

00009d8b ___ct__Q2_2PS8CSysCtrlFv

These are also present in the mao file:

0000a5d8 ___pinit__

0000a461 ___pure_virtual_called

0000966c ___sti___10_ps_sci_cpp_ce0c1b8d

00008b01 ___sti___13_ps_adc_if_cpp_ebd48f4a

000092ae ___sti___14_ps_pwr_chk_cpp_64299005

0000a204 ___sti___17_ps_proc_400hz_cpp_cc7ebeb6

00008a1e ___ct__Q2_2PS9CAdcExtIfFv

0000d24a _instance__Q2_2PS11CInterrupts

0000d240 _instance__Q2_2PS12CMcBsp_Intfc

0000d22c _instance__Q2_2PS14CPowerDn_CB_if

0000d220 _instance__Q2_2PS14CPowerUp_CB_if

0000d636 _instance__Q2_2PS14CProcess_400Hz

Isn't there a way to get verbose map files contents showing file symbol names by (Run) address with each section - currently my map files only shows object file names.

#include "ps_f28335.hpp"

#include "ps_comm_mngr.hpp"

#include "ps_pwr_chk.hpp"

#include "ps_gpio_if.hpp"

#include "ps_adc_if.hpp"

#include "ps_adc.hpp"

#include "ps_sci.hpp"

#include "ps_isr.hpp"　

extern void DeviceInit(void);

extern void StartCpuTimer0(void);

extern void EnableInterrupts(void);

extern void StartAdcSampling(void);

extern void StartMcBSPSampling(void);

PS::CAdcIf PS::CAdcIf::instance;

PS::CSysCtrl PS::CSysCtrl::instance;

PS::CGpio PS::CGpio::instance;

PS::CSciA PS::CSciA::instance;

PS::CSciB PS::CSciB::instance;

PS::CSciC PS::CSciC::instance;

PS::CGpioIf PS::CGpioIf::instance;

PS::CInterrupts PS::CInterrupts::instance;

PS::CMcBsp_Intfc PS::CMcBsp_Intfc::instance;

int main(void)

{

PS::CSciA* ptrCSciA = &PS::CSciA::GetInstance();

PS::CSciB* ptrCSciB = &PS::CSciB::GetInstance();

PS::CSciC* ptrCSciC = &PS::CSciC::GetInstance();

/**

* Initialize F28335 device-specific data, registers, etc.

*

*/

DeviceInit();

David,

I know that when you say keep steppingyou are referring to the steps through thr BOOT code, source code available for review from the RTS.  When I step through my project I can correletae the dissambly that I se with the code in the Boot asm file.

And when I step - as instructed by you and all instruction material - it is around the area in boot dealing with global object instatiantian that it appears that sometimes I branch eventually to by definition statements shown above and sometimes either execution appears to "hang" or it goes to main entry point.  Thhe success of this usually only occurs - when it occurs at all - after the code has already been copied from FLASH to RAM and I have reset a few times.  But never do I appear to have success when cycling power.

How can I verify / ensure that my object definitions are executed before entering main when cycling power ?

Greg,

Your local FAE has been advised of your issue, and should be in touch with you about it.

Regards,

David

David,

No contact yet since sending files.

Still further apparent progress on my part here, but two new questions I should have already asked.

I use an SD Traveler JTAG for CCS connection and instead of using the power jack, for power only I use the grey cable shipped with the controlCARD that normally provides power and a simple JTAG.  Will this connection - and with the SD Traveler disconnected - prevent booting to FLASH upon power cycle ?

And the other question involves the hi-hilted text shown below from the "C2000 Flash Common Issues/FAQs" Wiki (http://processors.wiki.ti.com/index.php/C2000_Flash_Common_Issues/FAQs) :

My question is "when is power to be re-applied" ?  And "where is the entry point to flash that the breakpoint is to be applied" [I got this now : "FLASH    0x33FFF6"] ?

Code Does Not Run Standalone

Q: My program runs correctly when debugging within CCS but when I attempt to run this standalone it does not work. Why is this occurring?

A: This can occur for a few different reasons:

1. The boot mode selection is not "jump to flash". Check the boot ROM guide and data manual for the particular device.
2. There are initialized sections allocated to load to RAM instead of flash. All initialized sections should have their load addresses allocated to flash so they can be programmed. The .cmd file needs to be checked to ensure that all initialized sections are assigned to flash. Section 3 of the Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) App. Note explains where each compiler generated section should be allocated.
3. If the code is time critical and needs to be run from RAM, it can be copied at runtime.
4. After you copy critical sections to RAM, make sure the copy really occurred - check the memory contents.
5. Try running the flash to RAM copy routine first. Some early functions may assume parts have been copied to RAM. For example, the delay function is used in the InitSysCtrl() function. This delay function is by default allocated to the functions TI's examples copy to RAM. If InitSysCtrl() is called before the copy to RAM then an exception will occur. TI is working to add comments to help avoid this pitfall. This also occurs with InitAdc().
6. An instruction was not added to branch to the beginning of application code at the flash entry point. This is discussed further in Section 6 of SPRA958.
7. 281x specific: In addition to the actual boot pins, the MP/MC pin needs to be pulled low to enable the boot ROM.

To debug this issue, step through the code and try to determine where it is going wrong. Here are some debug suggestions:

1. Flash the device
2. Turn off the power
3. Connect CCS and select "load symbols" only
4. Place a breakpoint at the entry point to flash [I got this now : "FLASH    0x33FFF6"]
5. Reset the part with the debugger and run - did you hit the breakpoint? If so the boot mode looks ok
6. Step the code until you find an issue.

Greg,

You're saying you use the on-board emulator USB cable connection on the ControlCard docking station to provide power to the board?  That should not interfere with device operation since the on-board emulator will not do anything unless it gets JTAG commands from the debugger.

On the FAQ questions, step #2 should say "Power-cycle the board" rather than "Turn off the power", because you're right there is no step telling you to turn back on the power.  In step #4, the entry point to the flash is the jump-to-flash bootmode target location.  For F2833x devices, this is address 0x33FFF6.  All the FAQ is telling you to do is check that the bootmode pins are set correctly by running through the bootloader.  You could just as easily step the code and see if you get to the CodeStartBranch file, which is what I had suggested previously.

Your FAE should be in touch.

- David

My expertise is in compilers, so I'm a bit lost in all these system startup details.  But I think I can shed some light on a few things.

Greg Oakes said:

in order to control the initialization order, the C++ constructors are executed in the order that these objects' definitions appear.

There is no relationship between the order in which global objects are defined and the order in which their constructors are called.  Here is a full discussion on it.  Any apparent order you see now is happenstance.  It could be different when you change compiler options, or compiler versions.

Greg Oakes said:

the _sti_ and ___ct__ symbols have addresses that seem not to cincide with the .pinit section

The .pinit section is described in the C2000 compiler manual, towards the end of the section titled Initialization Tables.

Hope this helps ...

-George

Thank you for the references George.  I am still checking out the proposed solution - wrapping static object inside a function - but I wanted to clarify that you are saying that placing static object definitions in a specific order, in succession of one another in the same file provides no guarantee that these definition statements will eb executed in the order in which they appear.

I was previously experiencing an apparently ransom object construction.  Before placing the definition statements in the same file each definition was placed in the *.cpp file that corresponds to the *.hpp file in which the object was declared (which is also the *.cpp file in which the static objects constructor itself is defined - a point which has no real bearing on this discussion since a constructor that is defined using its the fully qualified name could be located in any of the projects source files, I presume).

But by placing the object definitions in the same source code file the objects are reliably constructed in the order in which they appear in that source file, at least when booting to SARAM using the emulator.

Could it be that while these objects are reliably constructed when booting to SARAM, the constructuion order can still be different when booting to FLASH and copying all sections back to RAM ? 

Are object definitions such as those shown in the code snippet in my post above (and which are definitions of objects whose declarations and constructors are shown below - I show one of the objects' declarations/constructors) the type of entity that is allocated to .pinit ?

Is there an alternative to a wrapper such that if the specific source code files are copied from FLASH to specific areas in RAM (again presumably a specific ordering but one that is according to memory locations) then the objct definitions will be executed in the order in which they ultimately appear in RAM ?

Here is the declaration and constructor promised in the last post:

Appearing in *.hpp source file:

class CAdcIf

{

public:

private:

 static CAdcIf instance;

 CAdcIf(void);

 virtual ~CAdcIf(void){}

}

Appearing in *.cpp source file:

PS::CAdcIf::CAdcIf ()

{

memset(SampleTable.Buff, 0.0, sizeof (SampleTable.Buff));

memset(AdcBITError.Buff, true, sizeof (AdcBITError.Buff));

}

The FAQ link that deals with the static initialization Fiasco includes the following statement:

Since static local objects are constructed the first time control flows over their declaration (only), ...

The first time control flows over the declaration in the case of this embedded software program occurs when the static objects are defined - the objects do not reference each other in their constructors, so I would expect that I am in fact controlling the order in which the constructors are executed.

Greg Oakes said:

you are saying that placing static object definitions in a specific order, in succession of one another in the same file provides no guarantee that these definition statements will eb executed in the order in which they appear.

That's what I said.  But I owe you an apology.  I was incorrect.  Here is a quote from the book C++ Programming Language (3rd Ed) section 10.4.9 ...

Constructors for non-local objects in a translation unit are executed in the order their definitions occur.

Sorry about that!

-George

No apology necessary - you taught me something immeasurably valuable, were the TI compiler not so insistent that static objects be defined.  I was kind of wondering when reading the Fiasco how it could be only up to the order in which control flows over code in the header - with no opportunity to control that flow - as to when an object is defined.  Thanks for your great work on the compiler in helping us avoid all those Fiascos.

The FAE believes he has evidence that the instance definitions are getting executed - before Main is entered.  The evidence and the way it is generated are, however, not yet what I can consider conclusive.  Going to try it myself, now, and will let you know.

I have documented by disassembly statement citations the order in which boot code, and application code referenced by it, is executed.  After loading flash, disconnecting from target, reconnecting to target, loading symbols, reset, then step to code start branch, copy section, c_int00, my instance definitions, and then Main entry --- and this runs when using the emulator, but I get no ADC or SPI or SCI when power cycling.  The FAE turns off an LED via a GPIO which is SET in the GPIO constructor - but this does not tell me that the SysCtrl constructor (and other preliminary constructors) is executed before hand, as it needs to be in order to turn on the GPIO peripheral clock (I was a bit surprised to find, a while back, that GPIOs can not be initialized until after the GPIO peripheral clock is set.)

So, I am becoming familiar with the boot code.  With this familiarity I am emboldened to think I might have found a solution to another design problem : user selection of which of two Flash images to boot.  There is the fear that during program load to Flash the load can fail and with only image becoming corrupt if the upload fails, but with a known good image occupying the second storage location the processor can still be used - to try loading again.

Do you have any ideas/concepts on how this should be accomplished. 

I have considered allocating another GPIO to be read during boot which indicates which image to boot to.  This would of course require customizing the boot routine.

Greg Oakes said:

Do you have any ideas/concepts on how this should be accomplished. 

Sorry, but I have no expertise in what all happens between power up and when the boot routine (_c_int00) starts running.

Thanks and regards,

-George

George,

Would you mind putting me in touch with any of your colleagues, or other forum contributors, who may have even a smudgeon of such expertise, for solving both the pressing problem of booting my program to flash after power cycle (which involves copying everythign back to RAM and executing out of RAM), as wellas the soon to become pressing need to maintain two images in Flash and provide user control over which of these two images to boot to ?

Thanks, Greg

Factory team,

I spent some time last week onsite with Greg to determine what was going on. Some changes were made relative to C++ instances and what we found was that if we programmed the Flash via CCS/JTAG and hit run the design would function properly. However, if you power down and disconnect the emulator the design does not operate correctly when powered back up (ie. in standalone mode). Output signals do not have the correct waveforms.

What areas should be looked at that could explain the difference here? 

Tim

What do you mean by "Output signals do not have the correct waveforms" ?

You can try checking what is in the GEL file used by CCS.  It is possible that the gel script is enabling something that the code itself is not, such as a peripheral clock.

Right.  A bit too generous a description. 

There were no waveforms, in fact.  Well, we saw what appears to have possibly been a GPIO pulled up then set to zero, rather than 10kHz bursts of 500kHz data across a SPI associated GPIO, or the 50kHz interrupt monitored on another GPIO.

These signals are present when we appear to have been successful in using the JTAG emulator to boot to flash, which is followed by an ASM file copying flash to RAM, and then execution from RAM - all code and data executed from RAM after booting to flash.  Just no indication of execution when booting without the emulator (standalone - via power cycle).

All TI examples that provide instructions for verifying that a standalone boot to flash will work are pretty much identical and have been followed with FAE on the premises. 

So if there is something else that must be verified while using the emulator then please provide an explicit description - the FAE is not on premises at present. 

Tim mentioned the GEL file and ran a test that was to have indicated such interference and the test results were negative. 

If there is nothing else that can be verified while using the emulator then some other means of diagnostics might be available. 

How to debug with no emulator and no BIOS.

Regarding enabling clocks, via GEL or otherwise, if this is the primary area of investigation in situations like this then please recall the early description of the possible causes and the difficulty in ensuring the execution of non-local static object definitions which are placed before Main in the Main translation unit.  These are so placed because symptoms similar to those now present (when booting to flash standalone) were observed when the objects were defined in their own translation units.  In such an implementation the object definitions (constructors)  are executed in an unpredictable sequence, but placing then in sequence in the same translation unit ensures ordered execution.  The order is important in ensuring peripheral clocks are enabled before the peripheral is used, etc.

.pinit is supposed to initialize global static objects; which sections is for initialized non-local (but not Global) static objects ?  I think I see - using the emulator - all other non-local static objects in the .pinit table while looking at the Boot asm code, but not those located inthe Main translation unit.  Using the emulatror we come to a point - usually - in execution before args_main that the next instructions are those object defintion statements before Main in the Main translation unit, and they usually are executed.  Experienced advise on how to debug the Boot asm code - even if it means modifying it, if that has any promise in this siituation would be most welcome also ?

A simple test would be to load a simple program to FLASH and verify that it runs.  This will confirm the board/device is properly booting from FLASH.

You could also check the Xrsn pin to see if a reset is being issued.

Another test would be to attempt to boot the device standalone.  Then connect the emulator through CCS.  You might be able to get an idea of where the PC is at by viewing the disassembly.  After you connect, you can also load SYMBOLS only for the program and see if you can determine where it is in the code.

Thanks Daniel.  Those are some of the kinds of things I was hoping I might be able to try: booting standalone and connecting on the fly ? 

How exactly should one expect a program, the emulator, and CCS to behave in such a situation ?  And what exactly are the actions you allude to me taking ? Can we assume that we start the program by booting standalone (via power cycle, no emulator physical connection) ?  And follow this simply by making the physical emulator connection ?  Then is a "connect" via CCS necessary (which menu, selection, etc ?  What should be in place in the way of a target icon/selection on a pull down menu that I might need to configure/select ?  The program is running at the time of "connect", however "connect" is achieved ... so how do I inspect instructions (source, or assembly) or the program counter while the program is executing ?  Loading symbols only after connection when booting to flash using the emulator is something I have accomplished under the instruction material available in various Boot to Flash" TI documents; it's normally followed by a Reset, and stepping through the program to c-int00.  I have accomplished all of this when booting using the emulator - and these steps are supposed to confirm that the program is ready to be booted to flash stand-alone, but that's not totally true is it ?  Can those steps be varied (using the emulator) to determine better what's happening to prevent execution when not using the emulator ?

What kind of board are you running?  If you are controller a power stage with C2000, be aware that the device will be halted when you connect with the emulator through CCS.  This can cause PWM and GPIO signals to get stuck in their current state.  From what I read though, it seems you are using C2000 for communications mainly so you should be safe.

When I say "connect" I mean physically connecting the emulator to the JTAG pins and then connecting to the device itself using CCS debug. 

One way to do this in CCS is to-

First view your list of target configurations (View-> Target Configurations). 
Then right-click on the configuration you are using and choose "Launch Selected Configuration" which will launch the CCS Debug mode. 
Once the Debug mode is loaded, you will see the C28x core listed in the "Debug" window below the target configuration you launched. 
You can then connect to the C200 device (Run-> Connect Target) and try to determine where the code is halted at. 
If you load the program symbols, it will let you see the actual line of code it is at, instead of just the disassembly information. 

Do not perform a Reset after conenctiong since that would reset the device and cause you to lose any information available to determine if the device is running the code and perhaps getting stuck somewhere.

Beautiful, Daniel.  I think I should be able to work with this until I hit another wall or find my solution.  Is there any willingness on your end to take a small code dump and help with the additional expertise you have ?

I am developing on a controlCARD v1.0 w/ CCS 5.1.  The target is custom.  SCIs, McBSPs (in SPI mode), and ADCs are the peripherals; I only need to use GPIOs for McBSPs (Clock, Din, Dout, Chip Enable) and SCIs (RxData,TxData) and for a multitude of discrete ins and outs.

Thanks and let me know when you are available to receive that small code dump.

Do you have a docking station from the experimenter's kit?

What device are you on?  F28335?  If you send me a .out file compiled for FLASH operation, I can try running it on my side.

Daniel, Wow ! Much appreciated. 

Should we clarify a few things ? 

Device F28335.

ControlCARD V1.0

Docking-Stn USB-EMU [R3]

Spectrum Digital XDS560v2 LC (Traveler).

Does the .out file include ability to debug ?  We have a NDA so if your having the source code also would help obtain a resolution and make the task easier for you then I can make it available ... either through the FAE, or via your email address (preferred).  We could exchange email after getting email addresses in a Conversation ?

If you have a standalone project you can send me, that would be easiest.  

Is Tim your local FAE?  You can ask him to pass along the material.  Or send me an email at: my full name at ti dot com

Also, have you verified that you can run a simple example project from flash yet?