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.
Hello
I came from here:AM1808 mDDR SRR - Processors forum - Processors - TI E2E support forums
Now my customer is trying to understand the mDDR Usage Note descriptions in errata.
I understood the workaround for this issue, but my customer is saying if they could have more detailed information about this issue.
Considering the above Mulul's answer, if SRR command is *optional* on mDDR, it would be possible for mDDR to mis-understand incoming MSR command as SRR command at the first auto initialization sequence. If this condition is met, the memory controller on OMAP-L138 does not generate READ command at the next expected timing and finally mDDR could get stuck in SRR state. This is overall understanding on this issue. Correct, right ? Please let me confirm my understanding is correct or not.
If the above understanding is correct, we have some further questions :
1. The above *optional* is confusing. Can we understand this problem can happen on some mDDR parts *strictly* supporting JEDEC-compliant SRR feature including its command sequence and timing? Or, Does it mean some mDDR parts (I'm not sure such mDDR parts are existing in the market) which is roughly following JEDEC spec about SRR command might go into the problem ?
2. Why does the second MRS command (stated as a workaround) surely make mDDR exiting from SRR state ? Is this defined in JEDEC spec ? I know TI recommends to ask memory vendors when applying this workaround. So I think TI is expecting this scenario, but is not sure about this. This is possible work around -- Correct ?
Best Regards,
Naoki Kawada
Hi
My recollection on this is
Our EMIF controller is following JEDEC for both mDDR and DDR2 initialization. The SRR command is only applicable to mDDR, and our controller does not issue them as a part of mDDR initialization.
SRR command is an optional feature for mDDR, i.e., vendor chooses to implement or not.
However, OMAPL138 default powers up in DDR2 mode,it will issue a MRS command to Mode Register 1 for DDR2.This command looks exactly like an SRR command for mDDR, so memory from Vendor A if supporting the SRR command. Vendor B mDDR might not support this feature and therefore you may not see an issue.
That is why it is best to check with the memory vendor on the SRR feature support etc.
“Dual” initialization of mDDR in ROM/AISGEN works as work around, because the second initialization after first EMIF local reset/clock initialization makes the default state look like mDDR instead of DDR2.
Hope this helps.
Regards
Mukul
Hello Mukul,
Sorry for my delayed response.
My customer has decided to adopt this workaround even though they did not see any errors on mDDR supporting SRR feature.
We are now checking the initialization sequence for mDDR. Could you please take a look at :
www.tij.co.jp/.../spruh77a.pdf
15.2.13.1 Initializing Following Device Power Up or Reset
What part of the sequence should be done twice ? Or is it supposed to do set of all sequences twice ?
Please note their application will be booted from NOR-FlashROM (non AIS format). So they will have to configure mDDR in their application code (not ROM Bootloader).
Best Regards,
Naoki
Kawada,
From boot perspective other than the clocks and the mDDR slew configuration, we recommend that all DDR register configurations are done twice.
Here is a pseudo code for the usage.
if (CONFIGURE_EXTERNAL_MEMORY)
{
Initialize_ddr2configRegisters();
if (useMDDR)
{
if(doesMDDRsupportSRR)
{
intiialize_ddr2configRegisters(); // work around for mDDR interface with SRR support issue
}
Initialize_mddrSlewConfigSection()); // this can be done only once.
}
}
Another note or data point is that we have seen this issue impact configuration of mDDR only when the configuration is done from the ROM boot loader.
Regards,
Rahul
Hi Rahul,
Thanks for your answers. I'm not 100% sure what part of initialization sequence described in "Initializing Following Device Power Up or Reset" is for intiialize_ddr2configRegisters() and Initialize_mddrSlewConfigSection(). Because you are saying " boot perspective other than the clocks and the mDDR slew configuration", I assumed :
Initialize_ddr2configRegisters();
- step 7~16 in chapter "Initializing Following Device Power Up or Reset"
Initialize_mddrSlewConfigSection();
- step 6 in chapter "Initializing Following Device Power Up or Reset" for configuring DDR_SLEW
Is my understanding correct ?
If correct, your pseudo code is doing DDR_SLEW register configuration at *final step* of the workaround when mDDR supporting SRR feature is being supposed to use. This makes me confused -- is this really needed ?
Before issuing the previous post, my assumption for the correct initialization sequence for mDDR supporting SRR was :
1. do_fundamentalSetup()
- step 1~5 in chapter "Initializing Following Device Power Up or Reset"
2. Initialize_mddrSlewConfigSection
- step 6 in chapter "Initializing Following Device Power Up or Reset" for configuring DDR_SLEW
3. Initialize_ddr2configRegisters();
- step 7~16 in chapter "Initializing Following Device Power Up or Reset"
4. Again, Initialize_ddr2configRegisters();
- step 7~16 in chapter "Initializing Following Device Power Up or Reset"
5. Now workaround applied
What do you think of this countermeasure ?
Best Regards,
Naoki
Hi Naoki,
Sorry for the delayed response. We had a thanks giving break in the US so I wasn`t able to get to this.
Yes, your understanding is correct. From the ROM perspective, the following function is run twice to work around the issue.
DEVICE_DDRConfig(Uint32 ddrphycr, Uint32 sdcr, Uint32 sdtimr, Uint32 sdtimr2, Uint32 sdrcr, Uint32 sdcr2) { VUint32 data_tmp; VUint32 *DDRStart = (VUint32 *) &DDR_START; // Set the DDR2 to enable DEVICE_LPSCTransition(PSCNUM1, LPSC_EMIFB, PD0, PSC_ENABLE); if (SUBCHIPCFG->VTPIO_CTL & 0x00000040) { // Begin VTP Calibration SUBCHIPCFG->VTPIO_CTL |= DEVICE_VTPIO_CTL_IOPWRDN_MASK; // Set IOPWRDN bit to enable input buffer powerdown enable mode SUBCHIPCFG->VTPIO_CTL &= ~(DEVICE_VTPIO_CTL_POWERDN_MASK); // Clear POWERDN bit (enable VTP) // Pulse (low) CLRZ to initiate VTP IO Calibration SUBCHIPCFG->VTPIO_CTL |= DEVICE_VTPIO_CTL_CLKRZ_MASK; // Set CLRZ bit SUBCHIPCFG->VTPIO_CTL &= ~(DEVICE_VTPIO_CTL_CLKRZ_MASK); // Clear CLRZ bit (CLRZ should be low for at least 2ns) SUBCHIPCFG->VTPIO_CTL |= DEVICE_VTPIO_CTL_CLKRZ_MASK; // Set CLRZ bit // Polling READY bit to see when VTP calibration is done while(!((SUBCHIPCFG->VTPIO_CTL & DEVICE_VTPIO_CTL_READY_MASK)>>DEVICE_VTPIO_CTL_READY_SHIFT)); SUBCHIPCFG->VTPIO_CTL |= DEVICE_VTPIO_CTL_LOCK_MASK; // Set LOCK bit for static mode SUBCHIPCFG->VTPIO_CTL |= DEVICE_VTPIO_CTL_PWRSAVE_MASK; // Set PWRSAVE bit to save power // End VTP Calibration } // Config DDR timings EMIF3A->DDRPHYC1R = ddrphycr; // Clear the unlock bits (in case user accidentally set them) sdcr = sdcr & (~DEVICE_SDCR_BOOTUNLOCK_MASK) & (~DEVICE_SDCR_TIMUNLOCK_MASK); // Set SDCR with BOOTUNLOCK Set and TIMUNLOCK cleared EMIF3A->SDCR = sdcr | ((0x1 << DEVICE_SDCR_BOOTUNLOCK_SHIFT) & DEVICE_SDCR_BOOTUNLOCK_MASK); // Set SDCR with BOOTUNLOCK cleared and TIMUNLOCK set EMIF3A->SDCR = sdcr | ((0x1 << DEVICE_SDCR_TIMUNLOCK_SHIFT) & DEVICE_SDCR_TIMUNLOCK_MASK); // Check if this init is for mDDR if (sdcr & DEVICE_SDCR_MSDRAMEN_MASK) { // If it is, set SDCR2 with PASR and ROWSIZE PARAMS EMIF3A->SDCR2 = sdcr2; } EMIF3A->SDTIMR = sdtimr; EMIF3A->SDTIMR2 = sdtimr2; // Clear TIMUNLOCK bit EMIF3A->SDCR &= (~DEVICE_SDCR_TIMUNLOCK_MASK); EMIF3A->SDRCR = sdrcr; // Set the DDR2 to syncreset EMIF3A->SDRCR |= 0xC0000000; // Set to self-refresh, enable mclkstop DEVICE_LPSCTransition(PSCNUM1, LPSC_EMIFB, PD0, PSC_SYNCRESET); // Set the DDR2 to enable DEVICE_LPSCTransition(PSCNUM1, LPSC_EMIFB, PD0, PSC_ENABLE); EMIF3A->SDRCR &= ~(0xC0000000); // disable self-refresh // Dummy write/read to apply timing settings *DDRStart = 0xA55AA55A; // write data_tmp = *DDRStart; // read *DDRStart = data_tmp; return E_PASS; }
Please let me know if you have any further questions.
Regards,
Rahul