• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 102 subscribers
  • Views 1984 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM37x reconfigure SDRAM speed

Augustine Miu
Prodigy 220 points
Other Parts Discussed in Thread: TPS65920, OMAP3503, AM3703

Hi,

I am trying to reconfigure the SDRAM configuration from 166MHz to support the 200MHz SDRAM. 

I updated the following:

  1. CORE_CLK modified from 332MHz to 400MHz
  2. SDRC parameters: (I obtain the following values from the OMAP35x_DDR_register_calc_tools.xls spreadsheet from TI)
    1. SDRC_ACTIM_CTRLA_p: 0x7AE1B4C6
    2. SDRC_ACTIM_CTRLB_p: 0x00021217
    3. SDRC_RFR_CTRL_p: 0x0005E601
  3. GPMC parameter for NAND flash where the image resides.

 After I made all the changes, the bootloader seems to mostly bootup but with some warning/error regarding the I2C not able to access successfully. However, it till jumps to the image.

As it jumps to the image, the system hang where it's configuring the PMIC(TPS65920), which is I2C as well.

Can you let me know if I am missing anything when I configure the system to support 200MHz SDRAM?

Thanks

Augustine

  • 0
    TI__Guru**** 393215 points
    Hi,

    You will need to adjust your memory timings. See this wiki: processors.wiki.ti.com/.../Setting_up_AM37x_SDRC_registers
  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points

    Thanks for your response Biser Gatchev. 

    I did adjust the SDRC timing. I am curious when I adjust the CORE_CLK, is there something else that I need to adjust that might affect the I2C?

    Thanks

    Augustine

  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points

    Hi Biser,

    During the bootloader phase, our bootloader access the I2C3 to configure some of the IOs. For this, I got some warning saying the I2C Read/Write attempt failed, but it will be ok when it retries.

    During image running phase, it got stuck when it's doing OALTritonWrite(), which is to I2C1.

    Thanks again for your help.

    Augustine

  • 0 in reply to Augustine Miu
    TI__Guru**** 393215 points
    I have asked an AM37x expert to help on this, but response will be delayed, as he is out of office.
  • 0 in reply to Biser Gatchev-XID
    Prodigy 220 points

    Hi Biser,

    Are you able to get any response from the AM37x expert?

    Thanks in advance

  • 0 in reply to Augustine Miu
    Prodigy 220 points

    Hi Biser,

    After some trial and error, I was able to get the board to boot up. What I did is that after we set the I2C_CON register to start the I2C transaction, I would need to poll for the I2C_CON.STT bit. If the Start condition is not generated, I would need to set the I2C_CON to 0 and set it again to restart the I2C driver. With this check, I was able to boot up the board no problem. 

    Can you give me some insight as to why this is happening and what is a proper way to fix this? I have seen this problem until I adjust the SDRAM speed to 200MHz clock.

    Thanks

    Augustine

  • 0 in reply to Augustine Miu
    TI__Guru 65405 points
    Hi Augustine,

    I find it hard to find relation between your issue and DDR frequency but it is possible. Could you compare the serial clock line frequency (i2c1_scl) with both SDRAM speeds (166 MHz and 200 MHz)?
    In which mode you are using i2c and could you share i2c register's configuration?

    BR
    Tsvetolin Shulev
  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 220 points

    Hi Tsvetolin,

    Our AM37 I2C module is setup as master device and the I2C speed is 400KHz. I can't scoop the I2C1_SCL because I have no access to the signal from the hardware perspective. However, I do have access to I2C2_SCL and I2C3_SCL and the signal looks identical between running 166MHz vs 200MHz.

    Here are the registers dump when the failure occurred.

    I2C: REV = 0x0040
    I2C: IE = 0x0000
    I2C: STAT = 0x0000
    I2C: WE = 0x0000
    I2C: SYSS = 0x0001
    I2C: BUF = 0x0505
    I2C: CNT = 0x0001
    I2C: SYSC = 0x0001
    I2C: CON = 0x8601
    I2C: OA0 = 0x400e
    I2C: SA = 0x0050
    I2C: PSC = 0x0009
    I2C: SCLL = 0x0005
    I2C: SCLH = 0x0007
    I2C: SYSTEST = 0x01e0
    I2C: BUFSTAT = 0xc000
    I2C: OA1 = 0x0000
    I2C: OA2 = 0x0000
    I2C: OA3 = 0x0000
    I2C: ACTOA = 0x0000
    I2C: SBLOCK = 0x0000

    To give you the full picture, our older version of hardware has OMAP3503 processor on there and they are in production for years. We recently updated our software to support the following:

    1) AM3703 1GHz processor.

    2) sysclk frequency from 26MHz to 19.2MHz. We change the sysclk frequency because of an errata for AM37 processor regarding an USB issue (Advisory 2.1).

    The support of AM3703 processor and the new sysclk frequency is not in production yet. However, I've been using it for testing for a month on different units and I never see unit having trouble booting up. I really only see unit having trouble booting up after I made the modification to support the higher speed SDRAM. That's why I suspect the problem is with the core_clk change. However, it's still possible that the error is caused by the processor/sysclk change. So, any suggestion is appreciated.

    Thanks

    Augustine 

  • 0 in reply to Augustine Miu
    TI__Guru 68880 points

    Hi Augustine, here are some ideas:

    When you changed from 26MHz to 19.2MHz clock input, did you adjust all the the multiplier and divider values across all of the PLLs appropriately?  For example, DPLL4 (which drives the I2C module, among others), should have the following configuration:

    M = 360

    N = 7

    M2=9

    M3=16

    M4 = 5

    M5=4

    M6=3

    This may be done automatically by the software you are running (not sure if you are running with our linux distribution).  Other PLLs will need to be adjusted accordingly.  Incorrect clocking to the I2C module could possibly cause the problem you are seeing

    Also, are you truly running at 1GHz on the processor, and is that faster than what you ran previously?  There may be some timeouts in the I2C driver that are not adequate when running at those speeds.  The workaround you mentioned earlier may indicate that.

    Another idea, ensure that the bus is not busy (BB = 0) before you try to start a transaction.  Since you are working at faster speeds, the bus may still be busy the first time you try to start a transaction.  Again, not sure where your I2C driver originated from, but it should follow the flow diagrams in the TRM for successful I2C transactions.

    Regards,

    James