DDR_PADREF

Dave Pulvermacher said:

How bad is this?  Is there any way I can still use the DDR?

This seems fairly bad, since this is an impedance control pin for the DDR interface it could mean that you may never be able to properly interface with a DDR SDRAM, which is notoriously sensitive to such things. Unfortunately the functionality of the pin is not well defined in the documentation, so I don't have details, but I can say that we do not test for this condition, and therefore cannot guarantee functionality of the DDR interface in this sort of situation. It may be worth trying to communicate with the DDR if you already have your board up and running, but if your DDR is failing than you may have to do a respin. Note that even if it does work I would still recommend modifying your boards to have the appropriate resistor in future board spins to ensure long term reliability (I would not trust a production run with this defect).

Thanks to you both for the help.  We are definitely going to respin the board...but the goal now is to verify as much as we can prior to doing that.  Unfortunately this RAM issue will make that very difficult since we're unable to boot at this point.  

If we are unable to use RAM during the boot process, is there ANY thing else we can do to boot?  I’d very much like to verify flash and LCD functionality before respinning the board.  

Dave Pulvermacher said:

If we are unable to use RAM during the boot process, is there ANY thing else we can do to boot? 

You still have access to internal memory, so you can run smaller programs (i.e. up to the X-Loader / UBL stage, U-Boot and beyond is too large), what interfaces (UARTs, SD card, JTAG) and tools (JTAG emulator, CCS, etc.) do you have available?

Assuming you have the SD card interface available, you could take the existing X-Loader source and modify it to run your needed validation tests than boot it off of the SD card (this could also be done with the UART boot mode). X-Loader was designed to fit and execute in internal memory, with the primary purpose of initializing the DDR and loading the larger and more fully featured U-Boot, so it can be used as a base platform on a system with no DDR.

If you have additional tools such as a JTAG emulator and Code Composer Studio (CCS) you could write and load code directly from CCS for testing, this has the same max size limitation of the internal memory and would require more custom work on the tests, but is easier to debug.

Bernie,

We have the SD slot wired up, two UARTS (2 and 3) coming out to connectors and the JTAG interface (with the XDS510 Plus Emulator) available.  I guess at this point I'd like to find the fastest (easiest) way to get our validation tests done.  Our software engineer is busy with multiple projects so I'm trying to be efficient with his time.  

I appreciate your help!

I also assume you have purchased an AM3517 EVM as some point? If so the fastest/easiest solution if you have the XDS510 and CCS available would be to use the LogicPD test code (BSL) provided for the AM3517 EVM, as I just took a look at how the projects setup the memory map and they appear to use only internal memory, so you may be able to use the tests out of the box (if you are using the same hardware, for instance the same NAND device).

If you click on the access downloads link on this page it will have you log in and will give you a list of all the AM3517 downloads. Near the bottom of the downloads page there is a zip file called AM35xx Board Support Library (BSL) Files, which contains a variety of tests that can be run from CCS over the JTAG interface, including the sources which could be modified to suit your custom hardware. Note that this software is really only meant for testing and validation, and is not supported for production development for which only high level OSes are supported (namely Linux or Windows CE).

I do not know which kind of reworking tools you have access to, but I would solve this problem by either:

1. Removing the chip and place a thin wire to pad B12 (keep it in pace with capton tape) on the PCB and the resolder a new chip - Now you can access B12 at the wire. As long you only need to to to either the 1st or 2nd row of BGA balls this is "quite" easy :-)
2. Drill a hole at the precise location of Ball B12 from the back side of the PCB all the way through and hot air solder a wire to the ball - Alternative remove the chip and solder the wire to the chip and lead it through the just drilled hole... (This method of cause assume that you won't hurt any other vital track by the drilling :-)

Both methods can be succesfully applied (but you shouldn't plan for a 100% yield :-) with BGA down to 0.5mm - Getting to 0.4mm it's getting really tough... Using the ZCN 0.65mm package I therefore think you have a great posibility to rework the boards to actually support DDR operation for testing  :-)

 Best regards - Good luck
  Søren

Bernie,

Well, no luck yet.  My software engineer has used JTAG a great deal in the past but can't seem to get it working with this project (not even on the EVM board).  So, we're still monkeying around with it for now.  We will try again tomorrow.  

dave