SDRAM library

[SpacedCowboy]

Hi all,

So I'm testing out the board from this post, things are going smoothly apart from the SDRAM component...

I took the circuit pretty much from eez-open's project and he seems to be having no problems, so I'm reasonably sure the wiring is correct. What I hadn't realised was that lib_sdram was qualified only for certain SDRAMs - in my naivety I had thought an SDRAM was an SDRAM was an SDRAM...

Anyway, Seeed did the assembly of the hard-to-solder parts of the board, and did a pretty good job overall...

... but they rotated the SDRAM chip around by 180 degrees, which shorted ground to 3.3v when I switched on the first board. I modified the SDRAM test application slightly (I have an SDRAM_ENABLE line which has to be pulled low for 4 bits of the ADQ[16] bus on XS1_PORT_16A to be routed to the SDRAM rather than the default QSPI). I then remapped the ports thusly:

Code: Select all

on tile[SERVER_TILE] : out port               sdram_en        = XS1_PORT_1A;
on tile[SERVER_TILE] : out buffered port:32   sdram_dq_ah     = XS1_PORT_16A;
on tile[SERVER_TILE] : out buffered port:32   sdram_cas       = XS1_PORT_1L;
on tile[SERVER_TILE] : out buffered port:32   sdram_ras       = XS1_PORT_1M;
on tile[SERVER_TILE] : out buffered port:8    sdram_we        = XS1_PORT_1N;
on tile[SERVER_TILE] : out port               sdram_clk       = XS1_PORT_1O;
on tile[SERVER_TILE] : clock                  sdram_cb        = XS1_CLKBLK_2;

... and I get that 0xdeadbeef is being read back as 0 at location 0. Having found the thread about different SDRAMs I paid a bit more attention to the startup in my SDRAM chip (a winbond W9825G6KH). According to the power up on page 7, the DQM and CKE pins must be held high during the initial 200 uS delay. CKE is tied high, so I just needed to alter UDQM and LDQM. I tried adding the following code to the server.xc sdram_init() routine:

Code: Select all

  start_clock(cb);

  // begin added code
  // Hold UDQM,LDQM high during the next 200 uSecs. These are
  // driven by NOR connected to WE and CAS lines, so drive those low.
  partout_timed(we, 1, 0, t);
  partout_timed(cas, 1, 0, t);
  // end added code

  //Wait 200us for clock to stabilise
  T :> time;
  T when timerafter(time + 200 * TIMER_TICKS_PER_US) :> time;

... but that didn't help. I also tried bumping the clock-divider up to the maximum 10 (which makes it run *way* slower than the QSPI that the board successfully boots off). Again, no dice.

So there are several possibilities that I can see:

• The SDRAM chip is blown. Connecting it up the wrong way around was fatal and the game is over.
• Something went wrong elsewhere when the SDRAM was powered, maybe on the XMOS, again game over.
• The SDRAM is not compatible with lib_sdram.
• The signal integrity of the board is so bad, that it won't even run at 25MHz.

I don't *think* it's (4) - the QSPI runs fine booting the board, and I can flash at 50MHz using '--quad-spi-clock 50MHz' on the commandline. That leaves me with (3) or "it's buggered", unless I'm missing something else.

So (eventually :) questions:

• Has anyone used one of these SDRAMs before ? I have to rotate the SDRAMs on the remaining 4 boards anyway, and the IS45S16160G-7TLA1 is pin-compatible and currently available at mouser. If it's going to solve all the problems, it'd be worth it to just swap out the chips when I do the rotation.
• Have these changes (from the above-linked thread, by infiniteimprobability) been folded into the latest lib_sdram ?
• Is there anything else I could try ? :)

Cheers, and thanks for reading this far :)

Simon

[mon2]

The SDRAM chip is blown. Connecting it up the wrong way around was fatal and the game is over.

My vote is on this statement. Is the SDRAM soldered in correctly now for the device under test (DUT)? If the board was powered up even once with the SDRAM soldered incorrectly then we should assume the component is now destroyed. Better to take a fresh board -> do not power up the PCB!! -> fix the orientation of the SDRAM device -> then proceed to work with this fixed board. Most likely the SDRAM device will be warm to the touch or worse (careful of finger burns) if the power rails were ever reversed. An IR thermometer will be helpful to check the die temp of the SDRAM without contact.

[SpacedCowboy]

Thanks for the reply - I was leaning towards the "it's buggered" answer as well.

I actually do have one of those FLIR things you attach to your iPhone. I didn't notice it being overly hot (I did touch it, but it was a little time after the board had been switched off), but it's certainly worth a try.

Seeed still haven't got back to me, so we'll have to see what they want to do to fix the issue. In the meantime, I'll try (without connecting any power) rotating the SDRAM on one of the remaining 4 boards and go from there.

Cheers
Simon

[infiniteimprobability]

Nice looking board..

Regarding lib_sdram, it used to be the case that it would only play nicely with ISSI. There were significant updates to the low level code in 2017 to bring it into line with generic SDRAM setup. For example, both MICRON and ALLIANCE have now been tested in addition to ISSI. Here are some of the relevant commits (which are rolled into version 3.2.0 on xmos.com):

https://github.com/xmos/lib_sdram/commi ... 1b08b81156
https://github.com/xmos/lib_sdram/commi ... c8708ab00d

While it's not possible to say for sure that any SDRAM will work, they are all based on a JEDEC specification, so I would hope that windbond will work. If not, please file a bug though and we can take a look.

[SpacedCowboy]

Nice looking board..

Thanks :) I'd be happier if it was fully working, though :)

Regarding lib_sdram, it used to be the case that it would only play nicely with ISSI. There were significant updates to the low level code in 2017 to bring it into line with generic SDRAM setup. For example, both MICRON and ALLIANCE have now been tested in addition to ISSI. Here are some of the relevant commits (which are rolled into version 3.2.0 on xmos.com):

https://github.com/xmos/lib_sdram/commi ... 1b08b81156
https://github.com/xmos/lib_sdram/commi ... c8708ab00d

While it's not possible to say for sure that any SDRAM will work, they are all based on a JEDEC specification, so I would hope that windbond will work. If not, please file a bug though and we can take a look.

That's really good news :)

In the meantime, Janet (our resident miracle-worker w.r.t board rework) has done an excellent job rotating the SDRAM on an otherwise virgin board, so I'm going to solder up the rest of the components and we'll see if this next board will have better luck with the SDRAM access - it'll probably be the weekend before I get the time, but I'll report back afterwards.

Cheers
Simon

[mon2]

Janet (our resident miracle-worker w.r.t board rework) has done an excellent job

We believe you but get The Woz in there :) I will bet that he would love to do this soldering stuff again. I recall meeting him at a CES show in Chicago. One of the nicest guys you could meet. He actually allowed his security to let us group of teens in to meet with him face to face for a few minutes and chat. You don't forget such rare events anytime soon. Sir Clive Sinclair was there too and also met one of the Tramiel sons - offered me a job on the spot. Hindsight. Yup, very much dating myself...

Request your big boss to work on that time machine soon or perhaps you have one in the works already? :)

Designed some hardware for the Atari line back then and actually found the articles on the net recently. Pretty scary.