NIOS II JTAG Download errors

Just some additional info... I added a 1n/1u decoupling combo to the power pin of the header, and didn't help... also added a 10K0 pullupp to TDO. The more I think about this, it doesn't seem to be a JTAG problem... could the DDR core be locking up the NIOS processor somehow so it doesn't respond?

- I setup a test system with a nios processor and onchip RAM, and outside the NIOS processor, the Altera DDR example driver testing the DDR SDRAM. The DDR test was passing, and I could download code to the NIOS processor. This would seem to rule out a JTAG routing issue since the DDR is active, as well as the NIOS trying to download code. The only difference now is that the DDR core is separated from the processor.... does this make sense?

- Also, I setup another project where the processor and RAM were clocked by different PLLs - the processor @ 48MHz, and the DDR and 80M from separate clock inputs. I could then download to the onchip RAM and run, but when I tried to download to DDR, I got a verified fail?

jdhar,

It sounds like you are on the right track to debug this problem by isolating the DDR peripheral.

Since you mentioned SignalTap works (JTAG is probably not the problem), the issue could be how the DDR chip interfaces to the Avalon switch farbic through the DDR controller.

Have you used SignalTap to probe the DDR pins and the DDR controller Avalon interface signals? If the DDR controller is getting some bad signals from the DDR ram (i.e. poor solder connection, mis-wired DDR RAM connections to DDR controller), it could be sending random signals into Avalon perhaps tying up the whole system.

Regards,

-ATJ

--- Quote Start ---

originally posted by atjung@Feb 6 2006, 07:59 PM

jdhar,

it sounds like you are on the right track to debug this problem by isolating the ddr peripheral.

since you mentioned signaltap works (jtag is probably not the problem), the issue could be how the ddr chip interfaces to the avalon switch farbic through the ddr controller.

have you used signaltap to probe the ddr pins and the ddr controller avalon interface signals? if the ddr controller is getting some bad signals from the ddr ram (i.e. poor solder connection, mis-wired ddr ram connections to ddr controller), it could be sending random signals into avalon perhaps tying up the whole system.

regards,

-atj

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

--- quote end ---

--- Quote End ---

Thanks for the reply. You can&#39;t use SignalTap to probe the DDR pins directly, as it adversely affects the timings. I don&#39;t see how the DDR can be getting bad signals since I have run Alteras Example Driver (generated with the IP Core) on the board, and the test does pass. I have verified that it is in fact testing the RAM by lifting one of the data pins, causing it to fail.

I have two oscillators going to two PLLs on the board; I use one of the PLLS for the DDR, and another to clock the rest of the system (processor included)... this is working much better. I Can run the two at different speeds, and boot uClinux. If it wasn&#39;t for the extremely long compile time (1.5hours on my 3.2Ghz Dual core AMD!!), I would try going back to a single clock, but I think I will just be happy with the way it is right now.

I&#39;m not convinced it&#39;s JTAG either since SignalTap works, and I separated the core and processor and it still worked. But on the NIOS II EP2C35 reference design by Altera, they have it clocked by one clock, so I&#39;m sure it&#39;s not a bug in SOPC.... oh the problems!

--- Quote Start ---

originally posted by jdhar@Feb 7 2006, 10:06 AM

i have two oscillators going to two plls on the board; i use one of the plls for the ddr, and another to clock the rest of the system (processor included)... this is working much better. i can run the two at different speeds, and boot uclinux. if it wasn&#39;t for the extremely long compile time (1.5hours on my 3.2ghz dual core amd!!), i would try going back to a single clock, but i think i will just be happy with the way it is right now.

i&#39;m not convinced it&#39;s jtag either since signaltap works, and i separated the core and processor and it still worked. but on the nios ii ep2c35 reference design by altera, they have it clocked by one clock, so i&#39;m sure it&#39;s not a bug in sopc.... oh the problems!

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

--- quote end ---

--- Quote End ---

jdhar,

I wonder if the problem could be related to possible phase differences between the two oscillators/PLLs on the board causing the DDR controller to be in an unknown state. I believe the Altera 2C35 example uses one PLL to generate the clock to the system(c0 - sysclk) and DDR ram(c1 - write_clk_to_ddr_sdram). Looking at the PLL settings used the c1 clock used for the DDR ram has a -90 degree phase shift.

You should be able to narrow this down if you use SignalTap to probe the DDR peripheral interface to the Avalon switch fabric interface. Since the entire SOPC Builder system is an HDL file, you can grab nodes from the verilog/VHDL file. In fact, you can montior the Nios II processor interface signals to the Avalon switch fabric with SignalTap. I found the following App note on SignalTap (Using SignalTap II Embedded Logic Analyzers in SOPC Builder Systems) helpful in finding those internal nodes:

http://www.altera.com/literature/an/an323.pdf (http://www.altera.com/literature/an/an323.pdf)

I use ModelSim simulation to learn about the Avalon switch fabric interconnect signals (address, read/write, oe, readdata, writedata and waitrequest). All the Avalon signals should be synchronous at that stage so there should be no timing impact to the DDR pins.

By searching for the key Avalon control signals and monitoring them, it might offer a clue to why the target processor is "not responding" when you run SignalTap while downloading a program. You can probe the Nios processor signals or the DDR peripheral signals connecting to Avalon.

For example if the Nios II processor is trying to access DDR, but it has a waitrequest asserted from the DDR ram it will hold the Nios II processor in a wait state and could be locking out any other processor operations including JTAG debug used to download programs into memory. This might be the case since you mentioned when the DDR is removed from the system your programs download and run, but when you hook up the DDR ram to the system it starts to exhibit problems with connecting to the processor.

Regards,

-ATJ

That&#39;s an excellent suggestion about actually probing inside the Avalon bus; didn&#39;t think of that http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/smile.gif Do you know how much overhead signaltap adds to the system? I&#39;m already pushing the limits of my system (as I mentioned, the really long compile time!), and if I add SignalTap, I don&#39;t want it to cut the Fmax as it won&#39;t be realistic.

I will give it a try though, thx!

jdhar,

If your chip does not have the room for SignalTap, you can try a smaller system test to verify what is going on. Since Avalon is a fully synchrounous switch fabric, it should be easy to add and subtract components.

I would suggest to make a copy of your design and take out non-essential components to give yourself some extra resouces for SignalTap memory storage and more routing tracks for the LogicAnalyzer to probe internal signals.

By shrinking your system down you can then chose some of the fast compile options in Quartus II and turn off some of the performance vs area tradeoffs. Also smart recompile and incremental compilation has an impact on compilation time - I would suggest to read up on those features. Also not having a lot of memory makes windows swap to the disk a lot and really slows down compilation.

Regards,

-ATJ

--- Quote Start ---

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

well, im&#39; 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.

Rhaikh,

You might have already tried this, but have you tried slowing down the system? If you do have a board routing issue or slight timing issue, slowing down the system might get it to work.

Keith