DSP/BIOS linking failure when PWRM is enabled for C5515

Hmmm!

I did a findstr to every file under
     C:\Program Files\Texas Instruments\bios_5_41_02_14
and found instances of my two missing symbols in
    C:\Program Files\Texas Instruments\bios_5_41_02_14\packages\ti\bios\lib\bios5510.a55L
and several other *.55? files. 

Since BIOS_LIB_DIR is already defined as
     "C:\Program Files\Texas Instruments\bios_5_41_02_14\packages\ti\bios\lib",
in
     CCS project properties->C/C++ Build->Tool Settings->C5500 Linker->File Search Path
as an experiment, I added
     "bios5510.a55L"
under  (--library, -l), rebuilt the project and it linked successfully.

HOWEVER, I am developing code for a '5515, not a '5510, so this may not work out once I actually enable my code that employs PWRM.

Does there exist an equivalent of bios5510.a55L for the TMS320C5515?

For now, I will see whether my program runs correctly using the C5510 library, but it doesn't give me a strong sense of confidence.

Dan

OK, with a crude hack, I am able to work around this problem, but it is not an acceptable long-term solution.

I have, as previously described, built my code with bios5510.a55L linked in.

By setting breakpoints and inspecting disassembled code and the .map file, I have observed that the function
     PWRM_sleepDSP      in       bios5510.a55L : pwrm_slp.o55L (.text)
copies the contents of location
     _PWRM_DSMASK     in      pwrm.a55L : pwrm.o55L (.bss)
     which, at some point in the BIOS initialization, has been writtent to a value of 0x003F
into the ICR, executes several NOP's and then executes IDLE.

0x003F, however, while a valid value for the ICR in the C5510, causes an error in the C5515 that has the effect of resetting the ICR to 0x0000 instead.

I have added the line
     *( (Uint16 *) 0x01a035 ) = 0x03EF ;
to my main() routine, where
      0x01a035 is the address of _PWRM_DSMASK
      0x03EF is a valid value to write into the C5515 ICR to inhibit all its clock domains.

When I run this code, it appears to sleep and wake correctly.

HOWEVER, every time I build the project, I will have to examine the .map file for the address of _PWRM_DSMASK and, if it has changed since the previous build, patch it back into my main() routine and build the project a second time.  (The linker does not seem to find the symbol PWRM_DSMASK whether unadorned or prepended with one or two underscores.)

Again, I ask Does there exist an equivalent of bios5510.a55L for the TMS320C5515?

Dan

In post

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/142670.aspx

dated 26 Oct 2011, I have discovered the statement

"DSP/BIOS does not have PWRM support for C5515. It only supports C5509A and C5510."

Why not?  I've been developing for this chip on and off for a year and a half, so it's not too new to justify full support for it.

The same post continues

"For C5515, you could have a function in the idle loop or thread to configure the DSP in the appropriate low-power mode (CPU idle) from which it could wake up on an internal (or external) interrupt from a timer or any other peripheral."

so power management with the C5515 is clearly feasible, and the hack I describe above illustrates that at least some of the process of adapting '5510 code for '5515 use is trivial.

Come on, T.I. !

Dan

Dan,

As the other post you found says, there is no PWRM support for C5515.  And there won't be any developed for it. 

You’ll need to implement any power savings with your own code, based on the device data manuals and any available app notes.  I don’t know if there are any chip-support library (CSL) or other routines available for this. 

This thread was just moved to the BIOS forum.  I can’t tell where it came from but my guess is the C5000 DSP forum.  You might post a new thread there, without DSP/BIOS in the title, asking for any reference information or available code for C5515 power savings...

Scott 

OK, after using the CCSv4 disassembly view to observe what the PWRM code of DSP/BIOS for C5510 does and following recommendations of section 1.5.5.2 “IDLE3 Procedure” in “TMS3320C5515 DSP System User's Guide" ( SPRUFX5), I wrote my own deep sleep routine and it works great - as long as I connect the debugger to target and then Load Symbols for the code that resides in Flash.  When I boot the same code from Flash without connecting the debugger, however, it hangs when I attempt to write to the ICR after the first sleep / wake sequence.

I have discussed this in the C5000 forum:

http://e2e.ti.com/support/dsp/tms320c5000_power-efficient_dsps/f/109/t/190691.aspx

Dan

Dan,

I’m guessing here… but maybe there is something in your CCS GEL file that changes the behavior versus booting from Flash?  Have you seen section 2.1.5 “Bootloader Disables Peripheral Clocks” in the C5515 errata (http://www.ti.com/lit/er/sprz308a/sprz308a.pdf)?  I wonder if this might be part of the issue, something you wouldn’t see when running in CCS (because of something in the GEL), versus booting from Flash.  Still, I wouldn't think the CPU would hang when writing to the ICR.  I've not used a C5515, but have not seen this on any other C55x device.

Hopefully someone on the C5000 forum will have some input...

Scott

Hi Scott,

Thanks for your time.

I am using a modified, mostly disabled version of usbstk5515.gel which came with the ezDSP evaluation board. All functions in my .gel file include diagnostic GEL_TextOut(...) statements letting me know that they have been called and what they are doing.

When I "Launch TI Debugger" it calls StartUp() which, in my case, simply calls local function c5515_MapInit() which executes GEL_MapOn(), GEL_MapReset(), and multiple GEL_MapAdd(...) functions. I believe these only affect the state of the CCSv4 debugger, not the target.

When I successfully "Connect Target" (after clicking Retry) the debugger calls OnTargetConnect(). I have commented out all executable statements in this function, so it does nothing.

When I "Load Symbols" the debugger does not call OnPreFileLoaded() - I know this I get no GEL_TextOut() message reporting that OnPreFileLoaded() has run. [I do get such messages from OnPreFileLoaded() when I "Load Program" into the target.]

After "Load Symbols" the debugger does call OnFileLoaded(), but this does nothing but execute a GEL_TextOut( ) statement that lets me know it was called.

In fact, I just tried out a .gel file with nothing but GEL_TextOut(...) calls and I experience the same phenomenon.

Somehow, "Load Symbols" is the magic incantation that allows my code to run. "Connect Target" alone is not enough. Certainly puzzling.

Dan

Scott,

Thanks so much.  That did, indeed, solve my problem.

By the bye, I first opened my .tcf file with the DSP/BIOS Configuration Tool.
Under System -> Global Settings -> Properties I Unchecked Enable Real Time Analysis which added the line

bios.GBL.ENABLEINST = 0;

to my .tcf file, but that was not sufficient to solve my problems.

Adding the two lines you recommended did solve it. My .tcf file now ends with:

bios.GBL.ENABLEINST = 0;
// !GRAPHICAL_CONFIG_TOOL_SCRIPT_INSERT_POINT!

bios.HST.HOSTLINKTYPE = "NONE";
bios.RTDX.ENABLERTDX = 0;

prog.gen();

I assume that "prog.gen();" needs to be the last statement in the file.

Dan