Strange SDRAM behavior with OMAP-L137

Yes, it could be a timing configuration issue with the EMIFB.  Are you using the same memory as the EVM?  If not, then you need to update the EMIFB configuration for your memory.

Not exactly the same but same manufacturer. I have 7ns chips (IS42S16320B-7BLI) double the size of those in the EVM, 1ns slower. However I noticed that EMIFB is configured according to 7ns chip timing. Of course, this could suggest that the timings easily are on the edge and we need bigger margins than we think. I tried fooling around with the GEL file EMIFB timing values and was able to clearly worsen the situation ;) What I don't know is what exactly to change for the better because the values seem to affect each other to some extent.

I know I must use value 2 for PAGESIZE in SDCFG register. What other values to change, I don't really know. There are a couple values in evmomapl137_dsp.gel that don't follow the given equations or aren't given one in the EMIFB user's guide. They are

T_RFC field in SDTIM1 (set to 25 even though the equation gives (67.5ns / 7.55ns) - 1 = 8)

T_RAS_MAX field in SDTIM2 (set to 14 with a comment about not knowing how it should be calculated)

The datasheet shows quite similar timing values for almost all parameters between 6ns and 7ns chips when CAS latency is set to 2, so one could assume that isn't the most obvious reason but you never know. I'll try using SYSCLK5 as EMIFB source to slow things down and see if it makes a difference.

I did notice that the rise and fall times are quite critical because stronger pull-ups on the DQM lines made a slight difference.

Thanks for your reply, I'll get back when I have more experience. Please write back if this post raises any ideas.

Best Regards,

  Harri

Some more testing:

1. Changìng EMIFB clock source to SYSCLK5 and slowing it down to 35MHz had no positive effect. DQM lines show a nice 28ns low pulse and data is still wrong. Btw, doing two subsequent writes sometimes results to correct byte to be written, this has been the case before, too.

2. Pulling DQM lines up even stronger (1k3 resistors) don't improve the situation any further.

3. The CLK line has  a marginal overshoot but nothing serious to my understanding. Might be just the probes. I tried a stronger pull-up there, too but it brought nothing judged by eye from the scope display.

Having no success with a slower clock makes me think that rise and fall times aren't the culprit. Any suggestions? I'd really like to know what the correct EMIFB configuration values are in this case, or at least which are the most crucial ones.

Have you read through section A.2 (Software Configuration) in the EMIFB user guide (SPRUFL7)?  It walks you through the calculations for each parameter in the EMIFB registers.

Yes I have, very thoroughly. There are some differences in the settings made for EVMOMAP (described above) compared to that section. That's why I've been suspicious if even the EVM has required some tweaking to get those SDRAMs working. One thing I'm a bit stumped with is that using SYSCLK5 as the EMIFB primary clock seems to put things out of phase. DQMH/L lines change state on the CLK rising edge, thus being low (active) on the falling CLK edge which is wrong. I don't understand where this behavior can come from, because it's the EMIFB that's generating these signals and it would be strange that it would put itself out of phase. This could explain the wrong data written into the SDRAM (and sometimes correct because we're a hair off time) but I don't know of there's a way of inverting CLK to find out.

Are there some other bits than the PAGESIZE to change when I have double sized chips?

I got the attached GEL file from a colleague.  It shows how the EMIFB timings are calculated for a IS42S16160B-6BL memory.  I took a quick look at the timings used in this GEL file vs the timings given in the memory data sheet you mentioned and all look okay except for

• PAGESIZE (yours is 1024)
• CAS latency (I presume you are running >100MHz, so this should be set to 3)
• TRAS_MAX (your data sheet shows 100K)

I hope this helps.

Thanks for the file, Gus! It has a bit different presentation about how those fields are calculated but give the same results as the EMIFB user's guide. In the EVMOMAP gel I mentioned there are just raw integer values but they mostly yield those equations. Just the two fields I mentioned have much larger numbers than the results from those formulas.

Obviously this file is for 6ns chips, so I must use a bit larger values (which is the case in the gel I mentioned, even though the EVM has 6ns chips). I seem to have just the correct values (according to the IS42/45S16320B  data sheet p. 17), and I have tested CAS latency with both values without difference in the behavior.

So, basically there are two things I'm suspicious about. First the clock phase mentioned above (even RAS and CAS are low only during two consecutive rising edges of CLK). Then the difference between 8bit and 16/32 bit functionality which clearly shows that when the DQMH and DQML lines change at different times, things don't work. Writing 16 or 32 bits obviously causes both of them simultaneously going low on both chips and everything is ok. There aren't any shortages between those lines, which would cause just that behavior. So it must somehow result from the timing settings but how...

Thanks for your help! I know this is extremely difficult to solve remotely, but please post anything that comes into your mind that I could test further.

I'm still stuck with this. I tested the EVM and noticed that it has the same clock phase behavior mentioned above, and it still works. So, either CLK rises so little before RAS/CAS/DQMH etc. that it can't be seen clearly with a scope but it latches the events correctly.

I noticed one mistake in my design and wonder if it can have any effect. I have numbered the data lines in the opposite direction than the chip has. My lines run like this:

EMB_D0 -> DQ15

EMB_D1 -> DQ14

EMB_D2 -> DQ13

etc.

Address lines and all control lines are correct. I think the order of data lines isn't relevant as the physical placement of bits inside the memory chip should have no effect. Or is it different with SDRAMs?

Yeah, I don't think the issue with the data lines matters.  Originally I thought it might cause a problem when the EMIFB issues the load mode register command to the SDRAM, but the address lines are used to carry the data for the mode register, not the data lines.

Can you go back to the original description of the problem?  Why do you think it is not an endianness effect you are seeing?  Can you load and run a simple "Hello World" example from external memory or do you have problems here?

Ok, that's what I thought.

By endianness effect I meant that I'm not interpreting the order of bytes wrong when observing the memory window during debug. If I do a byte-by-byte writing test and the memory window is in 32-bit mode, the 32-bit words should fill up by 8-bit bytes right to left. Writing four bytes should make the first word look like 000000XX-0000XXXX-00XXXXXX-XXXXXXXX. This is what happens with the EVM. With my board it goes like 0000XX00-0000XXXX-XX00XXXX-XXXXXXXX.

An interesting observation is that if I do two back-to-back writes, I get occasional correct values into the memory. What is strange is that all memory values follow a pattern with some irregularities. Here's a small memory dump from a test writing 0x55:

0x30552930   0x00000034
0xB741EEBE 0x20202020
0x20555555   0x00000034
0xB741EEBE 0x20202020
0x32550055  0x00000034
0xB741EEBE 0x20202020
0x20555555  0x00000034
0xB741EEBE 0x20202020
0x20555555  0x00000034
0xB741EEBE 0x20202020
0x20555555 0x00000034
0xB741EEBE 0x20322020

As you can see, the less significant byte of the chips is correct more often. With most of my tests, the DQML bytes have been the only ones that ever get written correctly. Single stepping the write loop may cause the previously written byte to change (often to the corerct value!) when writing the next one. In other words, two bytes change with one write operation. This has kept me thinking of a refresh timing problem but, for the life of me, I can't find any settings that go better.

I can run code on SDRAM and it's no surprise because 16-bit and 32-bit accesses work fine. I'm tearing my hair on this one...

Haha, I did the exact same misinterpretation. Thought of it a bit more and came to the conclusion you describe. Just between my last post and yours, I went and swapped the DQM lines and guess what...

I suppose the occasional correct values were just that the data lines are tri-stated when not in use and sometimes keep their state long enough for the next operation to get that value.

I'm relieved that there weren't any PCB design flaws that cause problems (fingers crossed). Thanks a lot for your valuable help Gus, I really appreciate your effort!

Best Regards,

    Harri