Forums

Greg Oakes

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?