Trouble with TMS570LS31 HDK SDRAM

Tom Major

Other Parts Discussed in Thread: HALCOGEN

Hi,

I enabled SDRAM with EMIF on a TMS570LS31x Hercules Development Kit, with the help of this post

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/237341.aspx

But I seem to have trouble with accessing the data. I believe it has something to do with the fact that this SDRAM is connected over a 16 bit bus.

My litlle test program:

    volatile uint16 *p = (volatile uint16*)0x80000000;
    for (int i = 0; i < 16; i++) {
      *p++ = 0xABC0 + i;
    }

But in the debugger I see this data in the memory window:

80000000 abc0 abc0 abc2 abc2 abc4 abc4 abc6 abc6
80000010 abc8 abc8 abca abca abcc abcc abce abce

Every second write seems to go wrong somehow. Changing to 32bit pointer access does not help.

Any help is appreciated. Thanks.

over 12 years ago

0 Zhaohong Zhang over 12 years ago

TI__Mastermind 22715 points

Tom,

From your post, I guess that the data 0 pin of the SDRAM or MCU EMIF is shorted to ground. Would you please check with an ohmmeter?

Thanks and regards,

Zhaohong

0 Anthony F. Seely over 12 years ago in reply to Zhaohong Zhang

TI__Guru 68860 points

Zhaohong,

That could be the case, but it could also be a configuration issue with the bus width.

Tom please also past a dump of the EMIF control registers so we can analzye them.

For example, like this:

Or you can just type in the HEX values for the first set of registers whatever is easier for you.

Need to know 0xFCFFE808, 0xFCFFE80C, 0xFCFFE820, 0xFCFFE824 but the others wouldn't hurt.

Best Regards,

Anthony

Note: The image I posted was not from a board already configured for EMIF access to SDRAM; so don't worry if the values you have and I have are different. I just wanted a screenshot representing what I'd like to see from *your* environment.

0 Tom Major over 12 years ago in reply to Anthony F. Seely

Intellectual 260 points

Hello Zhaohong, Hello Anthony,

thank you very much for your quick response.

@Zhaohong:

I tried to check this, but think I found an error in the HDK schematics, but I am not sure.

I tried to meassure that on pin 42 "ETMDATA16" on J10. This pin is *not* shorted. On the HDK board, next to this pin, "K16" is printed with white paint. But in the schematics, page 5, this pin should be "K15" on the TMS570. So I am unsure if I catched the right pin for this test.

@Anthony:

Please find attached my EMIF configuration. In this screenshot you see my EMIF init calls as well. I think somewhere I have to tell that I am using a 16 bit RAM device, so 2 accesses are needed in a 32 bit Environment, but I dont know where to configure that.

Thanks and best regards,

Tom

0 Anthony F. Seely over 12 years ago in reply to Tom Major

TI__Guru 68860 points

Hi Tom,

My HDK has an ISSI IS42S16400F-7 device for SDRAM. (it's the square BGA down near the TI logo and near the two blue 3-pin CAN connectors).

The SDRAM geometry I am finding is programmed to: x16 bit bus, CAS latency of 3, 4 Bank, 8 column address lines. That matches the ISSI datasheet.

I checked your EMIF settings against that part number and they look ok for 90MHz EMIF clock and TA < 85C.

There's a couple issues:

1) The device can't run with EMIF at 90MHz, the maximum is 66.67MHz according to the datasheet (15ns emif clock period)

2) Assuming for the moment 90MHz - I would use a value of 0x6 and not 0x5 for the SDSRETR register. The ISSI spec is 70ns for -7 grade, and (5+1)*11 = 66ns a little short.

3) Now assuming you're running at 66.67MHz the main 'problem' spec would be the referesh timing; because the refresh register value of 0x493 (1171 decimal) amounts to 17us at 66.67MHz. You need to have 4096 refreshes within 64ms at < 85C so really this 17us needs to be reduced to 15.6us or less.

4) if you intend > 85C operation then the refresh time needs to be 4x faster (4096 in 16ms), so you'd be shooting for 3.9us for the refresh counter.

5) the other timings being set for 90MHz could be shortened for 66.67Mhz but I wouldn't expect a problem if they're longer. you just wouldn't be running near the max speed.

All that said, I don't think any of the above would really cause the problem you are seeing.

What exactly is your EMIF clock set to? This would be a PLL configuration option in HalCoGen?

Also in the meantime I'll set my HDK with the same settings as you have to try to reproduce the issue just in case I missed something.

-Anthony

0 Tom Major over 12 years ago in reply to Anthony F. Seely

Intellectual 260 points

Hi Anthony,

thanks for looking into this. I am not a SDRAM expert, this is the first time I have to configure such a device.

First, a general question, where do I have to configure that this is a 16 bit SDRAM. I can't see it nowhere in the HalCoGen configuration.

Next, I can't quite follow the timing issues in your comments. Please find attached my HalCoGen EMIF configuration:

1) where do you see this 90MHz? In my project, it is set to 80MHz, and according to the datasheet, the IS42S16400F-7 can run at 143MHz, so this should be fine? And where do you see a maximum of 66.7 in the datasheet?

2) You say 66ns is a little short. Can't follow here, I don't have 66ns in HalCoGen, I have 64 as trc if this is meant, and according to IS42S16400F-7 datasheet, trc 63ns minimum would be ok.

3) Again, I don't see 17us in my HalCoGen.

4) I currently have no need for >85C.

Is there a quick way in the debugger to check the actual EMIF clock? Like one prescaler register or so to look into?

Thank you very much.

Tom

0 Tom Major over 12 years ago in reply to Tom Major

Intellectual 260 points

second HalCoGen configuration page

0 Zhaohong Zhang over 12 years ago in reply to Tom Major

TI__Mastermind 22715 points

Tom,

I attaching some test code for HDK for your reference. You can see how EMIF and pin mux registers need to be configured. For the problem you reported, i would suggest you to pay special attention to the pin mux setting for EMIF data 0 pin.

3312.HDK_EMIF.zip

Thanks and regards,

Zhaohong

0 Anthony F. Seely over 12 years ago in reply to Tom Major

TI__Guru 68860 points

Hi Tom,

Some answers:

Tom Major said:

First, a general question, where do I have to configure that this is a 16 bit SDRAM. I can't see it nowhere in the HalCoGen configuration.

It doesn't appear to be there in HalCoGen, I suspect because the device only has 16 data bus lines. So programming the EMIF to 32-bit SDRAM would be an error. The EMIF doesn't support x8 SDRAM which is rare anyway, so x16 is really the only option with this part.

Tom Major said:

1) where do you see this 90MHz? In my project, it is set to 80MHz, and according to the datasheet, the IS42S16400F-7 can run at 143MHz, so this should be fine? And where do you see a maximum of 66.7 in the datasheet?

I see 90MHz in my project in the same place that you see 80MHz, probably your CPU frequency is set to 160MHz. I had mine at 180MHz.

The restriction to 66.7MHz EMIF is here:

A min clock cylce period of 15ns = 66.7MHz clock.

Tom Major said:

2) You say 66ns is a little short. Can't follow here, I don't have 66ns in HalCoGen, I have 64 as trc if this is meant, and according to IS42S16400F-7 datasheet, trc 63ns minimum would be ok.

The SDSRETR register has the value for txsr, not trc. I see that in the -7 column, trc is indeed 63ns but txsr is 70ns.

Tom Major said:

3) Again, I don't see 17us in my HalCoGen.

Right, you don't have it in set up that way in HalCoGen. You have it set correctly; but the clock frequency is too fast. So if you don't change the setting but you reduct the clock frequency to 66.7MHz you'll not be refreshing often enough. For reference 64ms / 4096 = 15.67us. So where you have 64ms and 4096 in HalCoGen, HalCoGen is going to calculate the number of clock cycles for 15.67us and you'll refresh once each time this counter expires.

This now gets a little complicated. What I saw in HalCoGen 3.05.00 is that the EMIF clock was "STUCK" at 90MHz and I couldn't change it.
To change the EMIF clock you have to go to the TMS570LS3137ZWT -> GCM tab and change the VCLK3 divider to a value of '2' (means /3).

Now, when I changed VCLK3 to 60MHz and went back to the EMIF tab, I noticed that the EMIF Clock tab was still saying 90MHz which is wrong.

So my big fear was that you'd run at 60MHz but with all the timings calculated for 90MHz. This would generally be ok as it'd be conservative, with the exception of the refresh counter which would be too long. If you don't refresh often enough, you can lose data in your SDRAM although you probably won't see that under normal conditions since usually there is a lot of guardband to that spec at room temp.

OK some GOOD NEWS. I found that if I do this:

1) change VCLK3 to 60MHz

2) save and close the project

3) open the project again

When the project is opened again, the EMIF clock reads 60MHz. So there must be a bug in this control where it's calculating only when the project opens instead of recalculating dynamically. I did file a bug report on that issue already. What it means is that if you do the three steps above, then you should see 60Mhz and your timings would be 60MHz.

Tom Major said:

4) I currently have no need for >85C.

OK that's fine. Then where you have the refresh period set to 64ms and the number of refresh to 4096 is correct.

Tom Major said:

Is there a quick way in the debugger to check the actual EMIF clock? Like one prescaler register or so to look into?

You could check the VCLK3 setting.

I flipped my HDK over and on the backside R41 is the series termination on the ECLK. I confirmed it was matching VCLK3 with an oscilloscope, even when the EMIF screen was reading 90MHz.

Best Regards,

Atnhony

0 Tom Major over 12 years ago in reply to Anthony F. Seely

Intellectual 260 points

Zhaohong,

thanks for the test code, will look into the mux settings as well.

Anthony,

thanks for making all of this clearer and pointing out the 16 bit SDRAM issue.

So I learned that I can not have 80MHz as EMIF clock, I overlooked this in the datasheet. (And I was deceived by the fact that HalCoGen offered me this as default setting)

Also I did not have txsr value in my SDRAM datasheet which was from 2008. Because of your remarks I searched again and found one from 2010, which had indeed the txsr value.

So I will look over my timing configurations, adjust them and will get back to you in the next couple of days once I have new results.

In the meantime, could you please post a screenshot from your HalCoGen/PLL page where I can see the PLL config for 180MHz?

Thank you very much.

Tom

0 Anthony F. Seely over 12 years ago in reply to Tom Major

TI__Guru 68860 points

Hi Tom,

Here's a screenshot of the PLL config for the TMS570LS3137ZWT at 180MHz. I think this is the default.

Best Regards,

Anthony

0 Anthony F. Seely over 12 years ago in reply to Anthony F. Seely

TI__Guru 68860 points

Hi Tom,

Are you still having trouble w. EMIF or did the clock freq. change work?

Thanks and Best Regards,

Anthony

0 Tom Major over 12 years ago in reply to Anthony F. Seely

Intellectual 260 points

Hi Anthony,

thanks for keeping this up, but I am out of office until next week. I will test this with the new settings next week and will definitely post the results and verify the answer if the problem is solved.

Thanks & regards,

Tom

0 Tom Major over 11 years ago in reply to Anthony F. Seely

Intellectual 260 points

Hello Anthony,

I looked over my timings and frequency and now it seems to work. I believe the main reason for that was changing the EMIF frequency to 60MHz. I have verified your post where you suggested that.

I have 2 more questions arising vom that:

1) Could you please look over my SDRAM timings. Are these ok for temperatures below 70C? I am especially not sure about twr. What does 2CLK in the data sheet mean? Like this: 1/(2x60)MHz = >= 8.3ns? I have put 10ns there.

2) SDRAM on the HDK board should be 8MB in size (0x80.0000, 64MBit chip). Available SDRAM Range on HDK is 128MB (please see next screenshot form the HDK manual, size 0x800.0000)

I made a little test program to test this, please see my code in IDE screenshot. I would have expeteced that RAM testing would fail above 0x80.0000. But it is not so. It seems to me the RAM is mirror the full 128MB, you can see this also in the screenshot, in the memory window. Why is that so and how can I fix it? The RAM should only occupy its 8MB without mirroring/continuing above that.

Thank you very much,

Tom

0 Anthony F. Seely over 11 years ago in reply to Tom Major

TI__Guru 68860 points

Hi Tom,

Regarding your questions.

Tom Major said:
1) Could you please look over my SDRAM timings. Are these ok for temperatures below 70C? I am especially not sure about twr. What does 2CLK in the data sheet mean? Like this: 1/(2x60)MHz = >= 8.3ns? I have put 10ns there.

It's 2 times the clock period, not frequency. So 60MHz = 16.6667ns and 2 * 16.6667ns = 33.333ns.

I attached a spreadsheet w. my calculations of the same. It would be good to confirm that these are the settings in the generated code; the output of HalCoGen after you generate. Note that this spreadsheet is specific to the ISSI IS42S16400F-7 but could be tweeked to another part by changing the SDRAM parameters section.6428.sdram_calc.xlsx

Tom Major said:
2) SDRAM on the HDK board should be 8MB in size (0x80.0000, 64MBit chip). Available SDRAM Range on HDK is 128MB (please see next screenshot form the HDK manual, size 0x800.0000)
I made a little test program to test this, please see my code in IDE screenshot. I would have expeteced that RAM testing would fail above 0x80.0000. But it is not so. It seems to me the RAM is mirror the full 128MB, you can see this also in the screenshot, in the memory window. Why is that so and how can I fix it? The RAM should only occupy its 8MB without mirroring/continuing above that.

Yes, 128MB makes sense because we could build a part with a 32-bit wide EMIF that could address two 64Mx16 devices (512MBit).

You can program the MPU in the CPU and any DMA's that you are using to restrict the memory to the 8MB that is available; this won't prevent the mirroring, but it will prevent the bus masters in your system from accessing the mirrored range. Exceptions to this would be the Ethernet MAC who's DMA doesn't have an MPU, and the USB host on the RM48 series (also doesn't have an MPU). DMA, FTU, HTU have MPUs.

Best Regards,

Anthony

0 Tom Major over 11 years ago in reply to Anthony F. Seely

Intellectual 260 points

Hi Anthony,

thanks for clarifying the mirroring issue with the 8MB SDRAM.

I looked into your spreadsheet and I changed my twr value to 34ns, so the values are the same now with the exception below (and the SDRAM is working as far as I can tell).

Further I observed 2 things:

- Txsr in your spreadsheet is set to 63ns, my value here is 70ns, as it is in the datasheet for this chip from August 2010. (We had this topic with txsr already a couple of post above).

- from Zhaohong Zhang post above, the TI emif testcode, file emif_config.c, line 436, twr is stated there as 15ns. Isn't this an error?

Also, in emif_config.h, line 18, it seems that not the whole RAM of 8MB is tested, but only 512k. Shouldn't this be 0x800000/4 instead?

Thanks & best regards,

Tom

0 Anthony F. Seely over 11 years ago in reply to Tom Major

TI__Guru 68860 points

Hi Tom,

Tom Major said:
- Txsr in your spreadsheet is set to 63ns, my value here is 70ns, as it is in the datasheet for this chip from August 2010. (We had this topic with txsr already a couple of post above).

Yes, you are right. Thanks for catching this mistake.

I fixed the spreadsheet:

5481.sdram_calc.xlsx

Tom Major said:
- from Zhaohong Zhang post above, the TI emif testcode, file emif_config.c, line 436, twr is stated there as 15ns. Isn't this an error?[
Also, in emif_config.h, line 18, it seems that not the whole RAM of 8MB is tested, but only 512k. Shouldn't this be 0x800000/4 instead?

I agree, but will let Zhaohong comment for more detail.

Best Regards,

Anthony

Arm-based microcontrollers

Arm-based microcontrollers forum

Trouble with TMS570LS31 HDK SDRAM