• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 97 subscribers
  • Views 220 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SDRAM-timer interrupts

Carl R
Intellectual 310 points
Other Parts Discussed in Thread: OMAP-L137

 Hello,    

 I'm using EMIFB on the OMAP137 to interface to an SDRAM.   I also am using the timer generated interrupts for a data acquisition

process. I'm finding that the interrupt routine is somehow interfereing with the SDRAM control circuit; Basically,the SDRAM becomes unrelaible,

ie the data contents are unstable,when interrupts are runng.  With interrupts disabled,the SDRAM is very stable.    I had assumed any processes necessary to

keep the SDRAM refreshed would be totally independent of other processor functions(like interrupts).  Any Suggestions?     thx  CR

  • 0
    TI__Mastermind 27585 points

    Hi Carl, can you give some more information:

    Are you using the OMAP-L137 EVM or a custom board?

    How frequently are the timer interrupts occurring?

    If you initialize the SDRAM, turn on the timer interrupts but don't ever write to the memory, and then disable the interrupts, are the SDRAM contents corrupt? Or does the corruption only show up when reading or writing while the interrupts are occuring?

    Jeff

  • 0 in reply to jc-ti
    Intellectual 310 points

    Jeff,

      Thx for the response.

        This is a custom board-  and it’s a problem at slightly elevated temp-   80 degrees C.

     

    I do know that if interrupts aren’t running,the SDRAM and OMAP work perfectly up to 200C.

     

     There are 2 timer generated interrupts:  SDTIM1 occurs 10 times second. It enables SDTIM2 which

    causes an interrupt every 12 usec,for a period of 4 millisecond.  So every 100 milliseconds,it has an interrupt occurring every

     12.8 usec, for a total elapsed time of 4 milliseconds.

     

     I’ll have to check the test you suggest- that’ll be a little tricky with my setup.

     

    Is there any interrupt from the EMIFB I might be inadvertently masking out?

     

                      Thx   CR

  • 0 in reply to Carl R
    TI__Mastermind 27585 points

    You shouldn't need any interrupts to prevent the contents of the SDRAM from being corrupted. This is handled by the controller automatically.

    Are you updating the data in the SDRAM every interrupt? How are you able to determine if the data is corrupted or not?

    Jeff

  • 0 in reply to jc-ti
    Intellectual 310 points

    The SDRAM data is being accessed more frequently during interrupts. Its easy enough to see its corrupted-

    I run a simple check. 

      A few questions:

     

    1.       Are there pullup/down resistor on the EMIFB lines that have to be programmed?  I think the GPIO lines have

    Pull-ups that are programmed;  I’d assumed the EMIFB were automatiocally set but maybe not. It appears there are

    No pull-ups on any lines.

    2.       I notice on the EVM board,there are series resistors in the data lines; can you comment

    3.       I’m running at 133 mhz SDRAM clock frequency; maybe I need to try reducing this.   

    4.       Is there any type of power save mode ,controlled by the PSC,the SDRAM EMIFB controller could be getting in to?

                                          Thx    CR 

  • 0 in reply to Carl R
    TI__Mastermind 27585 points

    1) No this does not need to be configured. External pull-ups are not required either.

    2) This is for signal integrity to reduce reflections.  Try slowing down the SDRAM speed and see if your issue is only related to high clock speeds. IBIS simulations would help determine if they are needed as well.

    3) Yes this is a good experiment.

    4) There is but only if you are manually setting that power save mode. It will not happen automatically.

    I'm trying to understand if the issue is with reads, writes, lack of refresh, or a combination. To figure this out can you:

    • Only perform reads and never write to the SDRAM after initialization. If that always works, then it is a write issue, otherwise it could be a read and/or refresh issue. 

    Jeff

  • 0 in reply to jc-ti
    Intellectual 310 points

    Ok, I'm trying to re-configure the EMIFB clock source by changing the CFGCHIP3 register after power up and boot.

     When running with CCS,this is normally taken care of with the GEL file, but I need to run with bootable code. So I'm wading thru

    chapter 6 in the system reference manual-which outlines a 13 step (!) sequence for modifying the PLL.  Its not clear to me yet

    if I need to go thru all these steps just to change the clock from DIV4.5  to SYSCLK5(so I can reduce the frequency). Normally this would be simple,

    taken care with the AISGEN GUI, but I can't use that because I have 2 files,arm and DSP.

      Pls keep in mind my problems are showing up at (relatively low) temperature- so I have to run from Boot Rom- no JTAG or CCS.

     Reason to ask atboutpull ups is they appear to be light;  the signals look current limited on a scope.     

     Writing a program now to tell if the prob is reads or writes      thx  CR