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.

[OMAPL138, mDDR] Clarifications about "DDR2/mDDR Controller: mDDR Usage Note" in errata

Other Parts Discussed in Thread: OMAP-L138, OMAPL138

Hello

I came from here:

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,

    We are checking out this request and will update you soon.

    Regards,
    Sivaraj K
  • 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,

    Thanks for your explanation. In fact, my customer does not see this problem on their target board, but I'm wondering applying the workaround might be a better choice for customers because there may be a possibility to change mDDR part after launching their product.
    I believe "dual" initialization sequence of mDDR irrespective of ROM/AISgen or user application will not cause any problem on mDDR, which I mean mDDR itself will work without any issues after dual initialization (Here, I don't care about any system issues such as initialization time delay).
    What do you think of this ?

    Best Regards,
    Naoki
  • Yes, doing this dual initialization should not cause any issue as far as we know. We did not see any issue in our testing and neither did the customer who found this issue and implemented a similar approach, of using the workaround across their design irrespective of the type of mddr memory.

    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

  • I'm waiting for your response.

    Thanks in advance.

    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.

    DDRconfig.c
    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

  • Hello Rahul,

    Hope you had a nice holiday.

    Thank you for your answer. The ROM code is very helpful. I'll talk with the customer and update the thread with verified answer if they does not have any further questions.

    Best Regards,
    Naoki