Forums

Can you provide more details about the 8 bit wide ddr2 2g modules you mention in your post?

I specifically would like to know how many DDR2 devices are on these modules.  The AM335x device can only source one load connected to the DQS[x] and DQ[x] net class signals and two loads connected to the CK and ADDR_CTRL net class signals.  This is specified in the AM335x data sheet section that describes DDR2 routing guidelines.

Regards,
Paul

The modules are the industrial grade of the micron used in the reference design the model number is mt47h256m8eb-25e it. The only difference I can find in our design is that we started with the beaglebone as a base design and then I was asked to increase the memory size based on the evm but I forgot to change the termination resistors from the 33ohm on the beagle bone to the 22ohm on the evm design. Could this cause the modules to fail to work properly and if so can I replace with solder bars as I see the minimum r value is 0.  The layout is as described in the reference manual with trace lengths as close to the same as possible and the schematic connections are identicle to the evm design except for the impedance. 

Thanks ed

Hello Ed,

try connecting your board to CodeComposer 5 and run DDR init script or AM335X EVM board init, to see if it goes throught. You can find more info on how to connect in this thread: http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/159102.aspx; mainly check the image: http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-81-01-00-00-58-53-86/2012_2D00_01_2D00_27-14h45_5F00_59.png

More info how to connect to JTAG interface can also be found at: http://beagleboard.org/static/beaglebone/a3/Docs/ccs-jtag-simple.htm; which helped me a lot with our custom board.

Best regards,

Miha

Hi Ed.

Did you have any luck with this?  My design uses dual MT47H256M8EB-25E:C, I set the DDR2 configuration parameters as per the EMIF page on the wiki and the design matches the EVM very closely.  SPL sails through the DDR2 configuration happily but the system freezes when I try to read from memory addresses in the supposedly configured SDRAM.

I have a FTDI-based JTAG solution on the board however the FTDI chip doesn't have an EEPROM so I can't make it look like a XDS100xx debugger in order to debug with CCS5 (is there a way to convince CCS5 to use an arbitrary JTAG connection?).  As such, I'm a little stuck on what other ways I can debug.

--Ash

The board house that layed ours out did the routing out of spec so we had to clock the ram at 50 MHz till we can get them to correct it

Ouch!  Well, that definitely sounds like it is worth a try.  Do you happen to have a patch that makes the switch?

You need to calculate a new clock rate in uboot

I gave that a try but regrettably this didn't solve the issue for me. Back to the drawing board I suppose...

Ed: thanks for you help in any case.

Success!  My board was missing a resistor on the nWE line---the CPU and the RAM weren't connected on this line.  Rather mundane fix I suppose but a good reminder to triple check all signal paths!

Ash,

if your design follows the design of the ICE , in what is related to the FTDI chip,

it is possible to clone the XDS100V2 configuration using the FTDI utility.

First you need a working ICE board (for example) to you read and save the configuration to a file in your pc.

Second, then, you write that file onto your new "virgin" board using the same utility, voila', you will have three new TI devices show up in the Windows device manager.

(two JTAG ports A, B,  and the USB-Serial Comm).

The FTDI application I have used  is: FT_Prog_v2.6.6.

http://www.ftdichip.com/Support/Utilities.htm

now you get a newer version, which should work anyway:

http://www.ftdichip.com/Support/Utilities/FT_Prog%20v2.6.8.zip

Hope it helps. Let us know about your success (or not).

Jure Z.

Unfortunately, my design does not include an EEPROM attached to the FTDI so it is not possible to program the FTDI chip with appropriate settings.  It sounds like Code Composer Studio/ICE-based debug tools effectively search for a USB PID, VID, and description field in order to identify the device.  Is there any way to tweak this code to make it more tolerant of other IDs (such as the standard ones from FTDI)?

I would say that perhaps your only chance is to rework your design and add the missing 93LC56BT-i/ot.

it connects to the ftdi chips using just 3 wires, plus ground and +3.3V.

good luck !

Jure Z