cannot put C6748 into DEEPSLEEP.

Hi Tuyen,

Please check these links whether it helps

http://processors.wiki.ti.com/index.php/Power_Module_for_C6748_and_OMAP-L138#Sleep_Modes

http://processors.wiki.ti.com/index.php/Power_Module_for_C6748_and_OMAP-L138#Constraints_for_Power_SLEEP_and_Power_DEEPSLEEP

you might find the following thread useful.

http://e2e.ti.com/support/dsp/omap_applications_processors/f/42/t/240930.aspx

Regards,

Shankari.

---------------------------------------------------------------------------------
Please click the Verify Answer button on this post if it answers your question.
---------------------------------------------------------------------------------

I figure out that the board cannot exit from the following loop. 

/* gate the VCLK at the PSC */
PMI_setModuleState(0, DDR_PSC, DDR_LPSC,
DDR_LPSC_DISABLE_STATE);

/* wait for transition to complete */
do {
PMI_getModuleState(0, DDR_PSC, DDR_LPSC, &lpscState);
} while(lpscState != DDR_LPSC_DISABLE_STATE);

It seems that mDDR cannot be clocked off because PMI_getModuleState always retrun PMI_BUSY.

Could anyone please give me some explanation why mDDR cannot be clocked off?

Thanks a lot,

Tuyen Nguyen

By the way, we are using TMS320 C6748ZWT E (generic secure) version.

As Shankari mentioned the wiki's would be relevant to make sure you are not missing anything

If you are seeing issues disabling EMIF clocks, make sure you are paying attention to criical code placement and putting DDR in self refresh

Perhaps this post helps

http://e2e.ti.com/support/embedded/linux/f/354/p/211525/842957.aspx#842957

Since you are using secure part, it would be good to make sure all IOPU's are unlocked. It might be a good idea to make sure you are able to accomplish the deep sleep on a non-secure part , so that we know for sure the issues are not due to non secure vs secure development

Regards

Mukul

We did successfully put non-secure chip into DEEPSLEEP. But with the same code, we could not put secure chip into DEEPSLEEP. When I use FORCE_BIT, I can clock off DDR. But I am not quite willing to use FORCE_BIT. 

IOPUs are all unlocked. And this post claim that IOPUs are used by ROM bootloader and only valid in SECURE mode. 

http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/202929.aspx

Our program run in NONSECURE mode.

Thanks,

Tuyen Nguyen

Was the non-secure deepsleep test done on identical hardware (same software, same hardware , just non secure vs secure device)?

If Force Bit works then I assume permissions/priv are ok. Force BIT just means that you are able to brute force shutdown the mDDR/DDR2 controller, however when you try to do it "gracefully" using PSC clock stop request , the clock stop request is not being acknowledged due to either some clocks still being enabled or some state machine of mDDR/DDR2 controller still active.

It would be good to confirm that everything kept the same, you are able  to get to DEEPSLEEP with RTC ALARM method , but not with DEEPSLEEP pin.

If that is the case, it would be good to reconfirm that the direction of the IO is truly set to input as required for deep sleep mode via deepsleep pin.

Dear Mukul,

Thanks for your reply!

HW of the two boards are the same. That's why we don't know what's going on. After FORCE_BIT, the loop breaks and DEEPSLEEP pin works as expected. Besides, we have tested the DIR and DATA of DEEPSLEEP pin. The only problem here is that we cannot clock off DDR gracefully. If we use FORCE_BIT for clock-off loop but no FORCE_BIT for clock-on loop when the device is waken up, the clock-on loop is also endless. In short, we have to use FORCE bit every time we want to clock on/off DDIR. And I still don't know why :(.

Tuyen Nguyen

Hi Tuyen

Sorry I have to ask you to reconfirm, your secure parts on the custom board work fine if you use the RTC ALARM mode instead of DEEPSLEEP pin mode, correct?

I want to make sure that you don't see the PSC hang or need for force bit etc, if deep sleep was via rtc alarm mode.

Regards

Mukul

Hi Tuyen

It would be good to get the value for the PSC1.MDSTAT register for the mDDR/DDR2 PSC (I believe it is PSC1.MDSTAT6) when it is hanging.

Regards

Mukul