NIOS II JTAG Download errors

--- Quote Start ---

originally posted by jdhar@Feb 5 2006, 09:51 AM

well, im' experiencing the same problem many others have... trying to bring up a new custom board.

<div align='right'><{post_snapback}> (index.php?act=findpost&pid=12552)

--- quote end ---

--- Quote End ---

Hey,

So we&#39;re having almost the same issue, with one difference. We&#39;ve narrowed it down to an SDRAM issue. I noticed that you said you set your sys libraries to use on chip RAM. We did that, and it worked; whereas it wouldn&#39;t work if we used SDRAM. Then we ran a memtest on the SDRAM, and I&#39;m getting sort of intermittent errors on just a walking-ones check on a single address line.

I mention it here because I&#39;m not sure exactly where to go with this. The data we get back is weird, I&#39;ll show you what I mean. It doesn&#39;t seem to be a stuck bit or stuck data line, because the behavior is not consistent. Here&#39;s the output of the memory test I wrote (which is basically the memtest project in the IDE):

-Data Bus Error: Expected 0x00000001, got 0xA001F981

-Data Bus Error: Expected 0x00000002, got 0x8000FD82

-Data Bus Error: Expected 0x00000004, got 0x0000F304

-Data Bus Error: Expected 0x00000008, got 0x0000E908

-Data Bus Error: Expected 0x00000010, got 0x00008110

-Data Bus Error: Expected 0x00000020, got 0x00000120

-Data Bus Error: Expected 0x00000100, got 0x00000000

-Data Bus Error: Expected 0x00004000, got 0x00000000

-Data Bus Error: Expected 0x00008000, got 0x00000000

The omitted patterns have been written and read properly. Running it again will get ALMOST the same errors, for example, a few ones had changed to zeroes and vice versa, or a different pattern will cause error. I don&#39;t understand how the same address could get written as 0xA001F981 from a walking-ones pattern.

I guess there&#39;s some problem with our timing, but I&#39;m not sure how to debug it effectively. Our only idea now is to run a looping write to a single address with constant data, go through each pin on our board, and compare the result on the oscope with what we expect.

Anyway, I posted this here because you seem to have a bit more experience debugging this sort of issue, I thought you might have some other ideas. Thanks.