Code placement for L138 DEEPSLEEP mode?

Mukul,

I didn’t find other people’s post on the same topic in the forum. I have also posted the question in OMAP forum and have bumped that thread.

The link you gave says that

.text

.bss

.vecs

.far

must reside in on-chip memory; I have also did experiments myself to see which sections needs to be in on-chip memory in order for waking-up to be succeed. I tested only 128KB L3, and the experimented started from all sections in L3 which had been tested to work for waking-up, to gradually allocate one or some of the sections to locations outside the chip. I have found that

.text

.bss

.const

.stack

.intvecs

must be in L3 for the device to wake up. The difference between my testing and the result at http://processors.wiki.ti.com/index.php/Power_Module_for_C6748_and_OMAP-L138#Constraints_for_Power_SLEEP_and_Power_DEEPSLEEP might due to the difference in structure between my project and the BIOS/PWRM, although it might also be possible that my configurations are not optimal enough. It is also seen that .data, .cint, .sysmem are not required for both mine and the wiki article result.

If I put all sections in L3 for a small project, and write some data to DDR2, and do

1. DDR2 into self-refresh
2. Put CPU into DEEPSLEEP (an external MSP430 pull DEEPSLEEP low)
3. Wake CPU (MSP430 pull DEEPSLEEP high)
4. DDR2 out of self-refresh

Then DDR2 are all preserved. However now I am testing the required code placement scheme for deepsleep’s waking up so I haven’t added DDR2 self-refresh to avoid complications and to keep the variables as less as possible.

In fact there is not a pair of functions intoDeepSleep() and outOfDeepSleep() as said in the top post. There is only one function sleep(), which

1. Sets pinmux so DEEPSLEEP/RTC_ALARM/GP0[8] pin to DEEPSLEEP
2. Set DEEPSLEEP.SLEEPENABLE
3. Tells MSP430 to pull DEEPSLEEP LOW
4. After waking up polls DEEPSLEEP.SLEEPCOMPLETE until it is set

And this sleep() function really have minimal dependencies on other functions expect it calls pinmux functions in step (1) above. So although the Wiki article you referred requires putting all .text into on-chip memory, I wonder why can’t we just put sleep() and the a few functions it calls into on-chip memory, and put all other functions in DDR2 as usual? I have in fact tried this with #pragma CODE_SECTION, but haven’t yet succeeded.

Another idea is that can we force sleep() to inline expand all functions it is called? If we can force the compiler to do this, for example, if

sleep() ->A() -> B() -> C() (for illustration, in fact just one level of call)

and we force sleep() to expand A(), B(), C() all within itself so it becomes a monolithic function, then we can only use #pragma CODE_SECTION to specify sleep() to be within on-chip memory without needing to do that for A(), B(), C() individually. Of course, when A(), B(), C() are called elsewhere they are still treated as normal function calls and should not be inline expanded. I haven’t found how to force the compiler to do this yet, but do you think it is a feasible idea? And is there a way to configure the compiler to behave like this (I also posted this inline expansion question in How to force inline all dependent functions calls into a single function in compiler forum)?

Paul

Mukul,

The information in your linked wiki article was important. I compared the address (0xC047F1A8) with the .map file and found that this address actually contains

loop0:

        B       loop0   

which immediately follows

AbortHandler:

UndefInstHandler:

;

; Disable all the interrupts

;

        MRS     r0, cpsr                  ; Read from CPSR

        ORR     r0, r0, #0xC0             ; Clear the IRQ and FIQ bits   

        MSR     cpsr_c, r0                  ; Write to CPSR

        ADD     r14, pc, #0               ; Store the return address

        LDR     pc, _CPUAbortHandler      ; Go to C handler

all are defined in Starterware > system_config_armv5 > exceptionhandler.asm. SPRUH77 says that “abort” exception indicates that the current memory access could not be completed. So I guess what actually happens is that one interrupt or some interrupts are pending after the CPU has been released from DEEPSLEEP and AINTC tries to jump to the ISR location, but as what you said PLL1 and DDR2 memory access has not been restored properly, and the ISR happens to be in the DDR2, so the memory fetch failed and AINTC simply jumps to the vector for abort exception.

If in the normal runtime environment without complications here such that memory device could be irresponsive, then we could simply add a breakpoint in each enabled ISR and we could know which ISR was triggered after the program halts there; but here since the pending ISR cannot be successfully executed even from its first instruction, the breakpoint method won’t be useful. In addition, the debug window won’t show a stack of function invocations in this very particular case (after just released from DEEPSLEEP, and after memory fetch has failed).

What can I do to find out which ISR the AINTC attempted to execute and has caused the problem? I looked at AINTC.GPVR (Global Prioritized Vector Register), HIPVR1 & 2, SRSR1-4, SECR1-4, and many bits are set. Which bit among these registers should I look at, or should I check registers other than these?

Paul

Hi Paul

I appreciate the update and summary on this. There are challenges in implementing the power management software almost from scratch , like you are trying to accomplish, and I am glad that you have been able to overcome most of it.

Your feedback on power optimization appnote is noted and I will keep in the log of to do items.

Regards

Mukul

Hi Mukul,

The SYS/BIOS does contain a function for entering saving modes including DEEPSLEEP which is

PMI_Status PMI_sleepCPU(PMI_Sleep state, unsigned scaleVoltage, unsigned sleepArg)

in

C:\ti\bios_6_33_04_39\packages\ti\sysbios\family\c674\pmi\ pmi_slp.c

On the other hand, is DEEPSLEEP code also included in the Linux PSP? I searched this Linux forum, and although there are questions related to the DEEPSLEEP mode, many are about devices other than L138 and none refers to the exact location (folder/package) of such code. I cannot confirm whether Linux PSP contains such code.

Could you give an answer on this?

Paul

Mukul,

I have created a new thread L138 DEEPSLEEP code in Linux PSP? for above question. Please look to that instead of this.

Paul