Hi everyone, I get some strang problems when I use adv_dbg_sys on my openrisc 1200 system.

My device is Altera Cyclone II EP2C35F672.

when I try to use "target remote :9999" command, I get a CRC error.

All information including selftest is pasted blow.

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: EP2C35F672 0x020B40DD 10

Target device 0, JTAG ID = 0x020b40dd
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - CPU(s) stalled.
SRAM test:
expected 11112222, read 11112222
expected 33334444, read 33334444
expected 55556666, read 55556666
expected 77778888, read 77778888
expected 9999aaaa, read 9999aaaa
expected bbbbcccc, read bbbbcccc
expected ddddeeee, read ddddeeee
expected ffff0000, read ffff0000
expected dedababa, read dedababa
SRAM test passed
Testing CPU0 (or1k) - writing instructions
Setting up CPU0
Starting CPU0!
Read npc = 00000010 ppc = 00000028 r1 = 00000005
Expected npc = 00000010 ppc = 00000028 r1 = 00000005
Read npc = 00000010 ppc = 00000028 r1 = 00000008
Expected npc = 00000010 ppc = 00000028 r1 = 00000008
Read npc = 00000028 ppc = 00000024 r1 = 0000000b
Expected npc = 00000028 ppc = 00000024 r1 = 0000000b
Read npc = 00000024 ppc = 00000020 r1 = 00000018
Expected npc = 00000024 ppc = 00000020 r1 = 00000018
Read npc = 00000020 ppc = 0000001c r1 = 00000031
Expected npc = 00000020 ppc = 0000001c r1 = 00000031
Read npc = 00000024 ppc = 00000020 r1 = 00000032
Expected npc = 00000024 ppc = 00000020 r1 = 00000032
Read npc = 00000014 ppc = 00000010 r1 = 00000063
Expected npc = 00000014 ppc = 00000010 r1 = 00000063
Read npc = 00000028 ppc = 00000024 r1 = 00000065
Expected npc = 00000028 ppc = 00000024 r1 = 00000065
Read npc = 00000010 ppc = 00000028 r1 = 000000c9
Expected npc = 00000010 ppc = 00000028 r1 = 000000c9
result = deaddead
*** Self-test PASSED ***
No watchpoint hardware found, HWP server not starting
HWP server listening on host xubuntu-or32 (0.0.0.0), port 9928, address family IPv4
JTAG bridge ready!
HWP server thread running!
CRC ERROR! Computed 0x99da2472, read CRC 0x5baf7cf6
Retry count exceeded! Abort!

CRC ERROR! match bit after write is 0 (computed CRC 0xcd6532cc)Retry count exceeded! Abort!


any help will be appreciated sincerely!

http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_self_test_fails

scroll down to "known issues". Your case might be "Example 1".

Thank you very much for your reply.

But my issue seems to be different. The whole self-test is passed and I use 32-bit ubuntu in virtual box. I think it should be something wrong with define files or other config files.

Besides, my or1200's edition is version 1.13 instead of version 3.

The adv_dbg_sys is obtained from minsoc project and the project now I use is construct by one of my classmates. In a addition, the version of the or1200 in my minsoc project is 2.0.

Is there any other possible solution about this problem?

I'm sorry for answering without paying due attention.

To experience CRC errors after the self test passed seems to me more a GDB/adv_jtag_bridge mismatch than real communication error. In case you are using or32-elf-gdb 7.0, I recommend you to use a patched version of gdb-6.8. Proceed this way: http://www.minsoc.com/gdb_install

Maybe that's not the correct answer yet. Nathan can probably help you further then.

Best regards,
Raul

Hi Raul, thanks for your help. I will try this solution and see whether it could fix the problem.

The minsoc project provides a installation shell: minsoc-install.sh which is acquired from www.minsoc.com/installation

Finding the file:gdb-6.8.tar.bz2 no longer exists at the ftp station, I edit the command to download gdb-6.8a.tar.bz2 to finish the installation. All of other commands remains as original except the ones contain gdb-6.8a.tar.bz2.

The revised shell runs well, but I don't know how to identify the gdb version and whether the patch has been added.So, where can I find this information?

Best Regards.

A CRC mismatch is an error in communication between adv_jtag_bridge program and the adv_dbg_if hardware core. It's not a common error, especially the way you're seeing it...the CRC is used to detect transient errors during communication, not structural errors in the way the system is set up. Once the self-test passes, it should be fairly hard to get a CRC error.

The only thing I can think of is that you've got a configuration mismatch - maybe adv_jtag_bridge is compiled for high-speed mode, and adv_dbg_if was synthesized for legacy / low speed mode. This *might* not cause a CRC error during self-test because the self-test never transfers more than one word of data at a time (always 32 bits), so it never has to deal with the ACK bit that legacy mode puts between every word.

Double-check that you've got matching options defined between your hardware and software. If that's not it, then I'm not sure what the other possibilities are...

Thank you so much for your reply. But things get more complicated now.

After I programed my device and try to connect it with GDB, I found it cannot pass the self test now. The message shows that the or1k cannot be stalled:

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: EP2C35F672 0x020B40DD 10

Target device 0, JTAG ID = 0x020b40dd
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - or1k is not stalled!
Self-test FAILED *** Bailing out!


But I didn't change anything, I just programed the device again.

BTW, the define words in Makefile of adv_dbg_sys show:
SUPPORT_LEGACY=false
USE_HISPEED=true

the adbg_define.v shows:
// If WISHBONE sub-module is supported uncomment the folowing line
`define DBG_WISHBONE_SUPPORTED

// If CPU_0 sub-module is supported uncomment the folowing line
`define DBG_CPU0_SUPPORTED

// If CPU_1 sub-module is supported uncomment the folowing line
//`define DBG_CPU1_SUPPORTED

// If this is defined, status bits will be skipped on burst
// writes to improve download speeds.
`define ADBG_USE_HISPEED

Is there any relevant parameters needs to be revise?

Best regards.

Hm, things have gotten worse. I think the bitstream was not downloaded correctly, or the bitstream is incorrect or corrupted - it appears that the adv_dbg_if isn't there at all. When I designed it, I neglected to add an ID register, so it can't be directly detected. But, this is failing at the first point in the sequence where the adv_dbg_if has to send back something specific, so I'm guessing it's not there at all.

Your combination of #defines looks OK...I suggest you make clean and rebuild adv_jtag_bridge just to be safe, and re-synthesizing the hardware system couldn't hurt either, especially considering the above problem.

Thanks for your suggestion.
Finally, I give up this project and tried another one. Now I am using minsoc project and attach my SDRAM IP core on it. The memory test works well but cpu test failed. It seems to be the problem of compability of the cpu and adbg system. Anyway, uart software in minsoc works properly.

I' m curious about why the same connection and same IP core works different, but I didn't figure it out.

At last, thank all of you for your help.

Best regards.

Hi Anthony,

I'm glad you got it running. Could I ask you if your system is working under a virtual machine? I have experienced some usb connectivity problems once in a while using a virtual machine. Hence, I would really like to have some feedback on adv_jtag_bridge on virtual machines. And again, the system works pretty well under Cygwin too, in case you want to do so.

Finally, did you use the trunk or release-0.9 version? If you went for trunk, could it be that you have a board set configuration to contribute to the project?

Best regards and thanks in advance,
Raul

Hi Raul,

Because of my limited knowledge, I might not able to provide all information you want, but I will try my best.

My environment is Xubuntu 10.04 LTS on VirtualBox 4.1.2 r73507.

My device is Cyclone II EP2C35F672C8 on UP-CUP_FPGA2C35-II board with the usbblaster adapter offered with the board.

My toolchain and minsoc is installed according to this page: http://www.minsoc.com/installation
First, I installed the preliminary development package such as gcc. But I forget the detail. I think it can be found on minsoc wiki. Then I followed the guide and export the setup folder, execute the minsoc-install.sh.

but I find the GDB6.8 is not available yet, so I change it to GDB6.8a in the installation bash file and left other things, including the patch, unchanged. The installation works OK.
If there is any development package required that I have not installed, I just install it by sudo apt-get install. But I'm sorry I forget what I have installed.

I just copy all of the .v file to window 7 and synthesize them and download .sof through quartus 9.1.

And the device can be attached to adbg system now if only I forward the usb port to the xubuntu in virtualbox.

There is another weird thing. I could only pass the self-test after I attached a SDRAM IP core and connected it to a SDRAM. It seems that the original on-chip memory didn't work properly. I have tried generic mode and LPM mode, but all of them failed to pass the test. The SDRAM IP core is from one of my school mate, I don't know where he got the codes.

That is my experience, I hope it is useful to you.

Now I am attempting to run linux on my project, and I've found different or1200 version could affect a lot on both adbg system section and others.

Best regards,

Anthony

Hi Anthony,



This is what I wanted to know. I was not sure that the cable connection and adbg would work reliably inside of Virtualbox.

Besides that, I wanted to know if you are using release-0.9 or our development version of minsoc?

Could you go to your minsoc directory and type: svn info

This is the result for a development version:
raul@mp-pc133:~/or1k/minsoc$ svn info
Path: .
URL: http://opencores.org/ocsvn/minsoc/minsoc/trunk
Repository Root: http://opencores.org/ocsvn/minsoc
Repository UUID: 1e56cc09-5d24-4cb8-85b2-5a87126a96e3
Revision: 103
Node Kind: directory
Schedule: normal
Last Changed Author: rfajardo
Last Changed Rev: 103
Last Changed Date: 2011-10-16 21:26:39 +0200 (Sun, 16 Oct 2011)




We are aware of the adbg test and or1200 incompatibility problems. But I don't think it will be addressed soon. Yes, I understood that you are trying to run Linux and are using an SDRAM controller. I also tried to answer some of your Linux questions on the other thread. I hope you make it work.

Best regards,
Raul