• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 602 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Memory requirements/code placement for SLEEP mode

john filo
Intellectual 260 points

Other Parts Discussed in Thread: OMAP-L138, SYSBIOS

I'm running SYS/BIOS-6.35 on an OMAP-L138 and would like to be able to use SYSBIOS's Power_sleepDSP().  I'm running into issues with placement of code/data in on-chip memory so that when the system comes out of SLEEP mode it does't try to execute any code that is in DDR until the DDR controller has been reenabled.

The Wiki (http://processors.wiki.ti.com/index.php/Power_Module_for_C6748_and_OMAP-L138#Constraints_for_Power_SLEEP_and_Power_DEEPSLEEP) recommends putting pretty much everything (.text, .stack, .far, .vecs) in L2 or L3.  For large programs, this obviously isn't a viable solution.  Power provides a mechanism for putting the critical PMI code on chip (Power.onChipRegion), but this doesn't address any of the HWI handlers that will get invoked.  I tried to explicitly move everything Hwi related on-chip , but at this point I have a few items that I haven't  been able to move there (e.g. ti_sysbios_family_c64p_Hwi_Module__state__V).  As a result, the Hwi handler fails coming out of SLEEP mode.  It seems to me like I must be missing something.  Is there a simple way to get all of SYS/BIOS's Hwi related code/data to link on-chip?

Thanks,

John Filo

  • 0
    TI__Mastermind 26780 points

    John,

    You need to place the “.far” section somewhere in internal memory to allow the Hwi module state structure to be accessed while PLL1 is bypassed. 

    Hopefully this is the last piece required for your particular application...

    Scott

  • 0 in reply to ScottG
    Intellectual 260 points

    Our .far section is quite large, so I'm not sure how I would do that.  I tied to place just the variable  ti_sysbios_family_c64p_Hwi_Module__state__V in L3 by adding the following to my SYSBIOS config file:

       Program.sectMap[".far:_ti_sysbios_family_c64p_Hwi_Module__state__V"] = "L3_CBA_RAM";

    The above symbol is the first thing in .far that is referenced by the Hwi dispatcher.  The above scheme worked fine for symbols in .text (e.g. ".text:_ti_sysbios_family_c64p_Hwi_dispatchAlways") but it didn't seem to have any effect on the above mentioned .far symbol.  Given that .far contains the system heap (at least that's my understanding), it doesn't seem practical to map the entire thing on-chip.  It seems like I need some way to tell SYSBIOS to allocate all of its Hwi related data structures on chip.  Any ideas on how to do this?

    Hopefully this is the last piece required for your particular application..

    I wish :)  I'm having all sorts of other DEEPSLEEP related issues, but I'll save those for another day.  

  • 0 in reply to john filo
    TI__Mastermind 26780 points

    John,

    OK.  I don’t know if it is possible to keep the module state structure from residing in .far.  I will have to look into that.

    One other thought… do you have a specific interrupt you are using for waking the device from SLEEP?  I wonder if maybe it could be configured as a non-dispatched interrupt, with the interrupt service fetch packet plugged directly with Hwi_plug()?  In that case, the Hwi dispatcher pieces would not have to be moved to on-chip memory.  Is this maybe an option?

    Scott

  • 0 in reply to ScottG
    Intellectual 260 points

    Scott Gary said:

    I wonder if maybe it could be configured as a non-dispatched interrupt, with the interrupt service fetch packet plugged directly with Hwi_plug()?  I


    Cool.  I overlooked that one.  I think that will do the trick.  Thanks!