• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 319 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.

Memory addressing problem

Virendra Verma
Prodigy 60 points

Hi guys,

 

This is my first posting in this forum and I am also new to device level programming. We are testing a new board with OMAP3 3503 processor on it. In the x-loader code we are testing the memory at address 0x80000000 where u-boot will be loaded. We wrote a simple memory test program which writes the address values at memory locations. We find that memory addresses are correctly written from 0x80000000 to 0x800007FC. As soon as test program writes at location 0x80000800, the value at address location 0x80000000 is modified to 0x80000800 in addition to being correctly written at address 0x80000800. If we continue writing further, all memory locations from 0x80000000 to 0x800007FC are overwritten with address values starting from  0x80000800.

Any idea what is going on here? Is this x-loader configuration issue or manufacturing defect? All the boards from the same lot behave same way. However, the test passes on older boards.

 

Thanks. 

  • 0
    TI__Mastermind 41665 points

    Virendra Verma said:
    Any idea what is going on here? Is this x-loader configuration issue or manufacturing defect?

    My first guess would be manufacturing defect, since you say prior hardware builds worked, assuming they were of the same hardware (same memory) and same software.

    The behavior you are getting of the memory repeating past a certain address would typically mean that one of your address signals is not making it to the memory, which could be consistent with a hardware problem, depending on the type of memory you are using with the OMAP3 and how your board is laid out, you may be able to probe the address signals directly with a scope. Since you are rolling over at 0x800 into the memory this would mean that the 11th byte level (9th for a 32 bit address) address line is not asserting on the memory, which could be due to a broken trace ball bad ball connection, etc. Which specific pin would depend on your DDR geometry (RAS, CAS, bus width).

  • 0 in reply to Bernie Thompson TI
    Prodigy 60 points

    Thanks, Bernie. That is what we are suspecting.

    I believe that address and data are multiplexed on the bus. I read somewhere that in non-multiplex mode the memory addressing is limited to 2K. Do you think this could be a factor? How do you verify addressing mode? Is it configrable parameter, if so how to set it?

    Thanks for your help and prompt reply.

    -- Virendra 

  • 0 in reply to Virendra Verma
    Genius 3685 points

    Hi Virendra,

    I think the 2K address limit you are referring to is the one applying for the GPMC in non-muxed mode. GPMC is used for connection of devices like NOR/NAND/SRAM, which is another interface than the SDRC used for connecting LRDDR. The 2K address limit is therefore not the problem you are seeing. I agree with Bernie on the most likely options for the source of the problem. Did you change the DDR vendor/type? In given case you might need to adjust the SDRC settings as suggested by Bernie. Information about setting CAS/RAS/Addressing mux scheme/etc. can be found in the OMAP3 TRM (spruf98g.pdf)  chapter "11.2 SDRAM Controller (SDRC) Subsystem"...

    Best regards - I hope this helps - Good luck
      Søren

  • 0 in reply to Soren Steen Christensen
    Prodigy 60 points

    Thanks, Soren.

    Yes, it turns out that this board has different memory chip what we had before. You are absolutely right we need to adjust SDRAM Controller Subsystem.

    Thanks again. 

  • 0 in reply to Virendra Verma
    Prodigy 60 points

    Problem solved. The new memory chip is MT46H32M32LFCM-6 from Micron Technology. Setting CAS width to 9 bits and RAS width to 13 bits solves the problem.

    I also found this link quite useful

    http://processors.wiki.ti.com/index.php/Setting_up_OMAP35x_SDRC_registers

    Thanks Bernie and Soren to lead me in the right direction.