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.

Code into 8KB ARM RAM, then fail resuming from DEEPSLEEP

Other Parts Discussed in Thread: OMAP-L138

Hi,

According to SPRUH77 Figure 1-1. OMAP-L138 Applications Processor Block Diagram L138’s ARM core has 8KB RAM inside the core, which should be very fast. If I want to place some code inside this area, is there any pre-configuration (in GEL) I need to do before I can use this area?

I tried to put the function responsible for entering-plus-exiting DEEPSLEEP mode into this area. However after external device releases the DEEPSLEEP pin to high and I then reconnect to ARM (removed GEL first to prevent it from altering processor status due to its OnTargetConnect( ) function), I would find ARM PC (programmer counter) points at some unknown location which does not contain valid code: sometimes it points to infinite loop after AbortHandler() (defined in Starterware system_config exceptionhandler.asm) which indicates memory-fetch error, sometimes  the PC even points to ARM local 64KB ROM location.

As a comparison, if I put the function for entering-plus-exiting in 128KB shared RAM, then if a memory-fetch error happens at least PC would ALWAYS point to the code following abort mode (due to memory-fetch error), but NEVER point to ARM local 64KB ROM.

Repeated experiments show that this problem when placing enter-and-exit DEEPSLEEP code in 8KB ARM RAM happens intermittently: a few times after DEEPLSEEP pin released to high the device can resume as expected, but at most of the times not.

Because the problem is intermittent I suspected that there might be some timing synchronization issues between the CPU and DDR2, because after exiting DEEPSLEEP and take DDR2 out of self-refresh we would then execute code which is placed in the DDR2. SPRUH77 section 15.2.8 Self-Refresh Mode on page 3 requires delaying for minimum T_XSNR+1 / T_XSRD+1 DDR_CLK cycles before issuing command to DDR2 controller, which we exactly followed. However even after adding this wait the problem persists.

We have never tried to place code into this small 8KB ARM RAM before so we have little experience with associated problems. Could someone share ideas on the cause of the problem?

 

Paul