Clocking configuration generated from AISgen

Reagen,

There are no known issue with the AISGen tool with regards to DDR2? Have you ensured that the DDR2 timings you are using match with the timing spreadsheet provided here:

http://processors.wiki.ti.com/index.php/OMAP-L138_Hardware_Design_Guide#DDR2.2FmDDR

I will take a look at the cfg file and let you know if there is something obvious that jumps out.

Regards,

Rahul

Rahul,

Thanks for jumping into the discussion.  I'm the end customer that is working with Reagen.  We are just trying to get someone to double check our AISGen configuration script used to create our .bin files.  With the information provided in the original post (DDR2 part number, clock speed, etc), do you agree that we've configured the DDR2 controller correctly on the C6748?  Reagen has gotten hung up on the fact that AISGen might output numbers that write to reserved bits in the C6748.  That should also be looked into, but I'm really just after someone double checking our DDR2 configuration numbers.

Thanks, Dean

Dean,

Have you tried using that spreadsheet? The timing numbers seem to be coming out correctly, but that spreadsheet would also show how to configure the memory controller registers to match the configuration for the memory device you're using, more-so than just the timing. If you supply the part # for the memory device, I could double-check this as well.

Taking a step back a little bit though, you mentioned before that you were experiencing random lockups. What did you mean by this? Are you able to boot up properly from external flash, with proper operation initially? If not, what exactly is happening?

-Reagan

Reagan,

Yes I've used the spreadsheet.  If you want the part # for our DDR memory device, check your original post in this thread.  That has been the goal this entire time.  Find somebody within TI that knows DDR2 memory (or the C6748 DDR2 controller) and have them double check my work using the memory device datasheet.

We are having random lockups on our boards.  Yes we are able to boot correctly, yes we are able to run our application correctly (at least for a while).  At some random time, and in some random area of our application, our product locks up.  This could take 5 minutes or 1 hour, but it always locks up.  It might be software related, it might be MFG process related, or it could be DDR2 timing related.  I'm just trying to find someone to verify that our DDR2 timings look correct so I can rule that out.

- Dean

Dean,

If it's taking that long to lock up, the clocking on the DDR2 is not the problem. Generally problems like this stem from application code.

Is this locking up occuring in a debug environment, when it's running freely, or both? And what exactly happens when it's "locking up"?

Regards,
Reagan

Apparently it is too difficult to double check our DDR2 settings.  I really don't understand why one of the TI reps couldn't take the DDR2 part number, look up the data sheet, plug the numbers into the C6748 DDR2 Memory Controller Speadsheet, and make sure we did everything correctly.

At any rate, enough time has elapsed since I originally asked for help, that we're now 95% sure it is a MFG process problem.  Thanks anyway.

- Dean

Dean,

I mentioned previously that the timing configurations were correct. Since you said it was happening later on during run-time, it tells us that configurations made during initialization are likely fine. From there, I was trying to just narrow down the problem, since it's seems more-so to be software. Obviously there isn't a certainty behind this, but that just sticks out right now for likely causes.

-Reagan