Hello all,

I am getting a strange CRC error when i "load" on gdb. Im using gdb 6.8 and a xupv5-lx110t board.

here is my log

$ adv_jtag_bridge -b ~/bsd_files xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC5VLX110T_FF1136 0x72AD6093 10
1: XCCACE 0x0A001093 8
2: xc95144xl_cs144 0x59608093 8
3: XCF32P_FS48 0xF5059093 16
4: XCF32P_FS48 0xF5059093 16

Target device 0, JTAG ID = 0x72ad6093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
No watchpoint hardware found, HWP server not starting
HWP server listening on host longaville (0.0.0.0), port 9928, address family IPv4
HWP server thread running!
JTAG bridge ready!
CRC ERROR! match bit after write is 0 (computed CRC 0xe652ffc8)Retry count exceeded! Abort!
-------
GDB log :
$ /opt/gdb_stable/bin/or32-elf-gdb uart.or32
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later " target="_blank">http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=or32-elf"...
(gdb) target remote :9999
Remote debugging using :9999
0x00000100 in _reset_vector ()
(gdb) load
Loading section .reset, size 0x190 lma 0x0
Remote communication error: Connection reset by peer.
(gdb)

Thank you very much for your help,
Raghu

adv_jtag_bridge is talking to the cable and the hard TAP, but it doesn't look like it's talking to the internal TAP (the BSCAN block). I suspect either you have the wrong options defined in your HDL, your synthesis is wrong, or your bitstream isn't downloaded correctly.

Make sure you're using the xilinx_internal_jtag TAP, and make sure you're using the right defines for the Virtex-5. Then resynthesize, and download the bitstream to the FPGA before starting adv_jtag_bridge.

Thank you! like you said, it was a problem with my synthesis. Works great now.

The board I use is a XUPV5-LX110T (ml509 basically).

Hi everyone,

I'm in the process of trying to get minsoc running on a Digilent Atlys board (Spartan 6) and I'm running into a similar CRC error.

adv_jtag_bridge output:

./adv_jtag_bridge -b /opt/Xilinx/13.3/ISE_DS/ISE/spartan6/data xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC6SLX45_FGG484 0x34008093 6

Target device 0, JTAG ID = 0x34008093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
JSP server listening on host rex (0.0.0.0), port 9944, address family IPv4
JSP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 0 at startup! 'max retries'
CRC ERROR! Computed 0x2d0251ab, read CRC 0x761
Retry count exceeded! Abort!

ERROR reading DCR 1 at startup! 'CRC mismatch'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 2 at startup! 'max retries'
CRC ERROR! Computed 0xdebb20e3, read CRC 0x2600
Retry count exceeded! Abort!

ERROR reading DCR 3 at startup! 'CRC mismatch'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 4 at startup! 'max retries'
CRC ERROR! Computed 0xdebb20e3, read CRC 0x0
Retry count exceeded! Abort!

ERROR reading DCR 5 at startup! 'CRC mismatch'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 6 at startup! 'max retries'
CRC ERROR! Computed 0xdebb20e3, read CRC 0x0
Retry count exceeded! Abort!

ERROR reading DCR 7 at startup! 'CRC mismatch'
No watchpoint hardware found, HWP server not starting
HWP server listening on host rex (0.0.0.0), port 9928, address family IPv4
JTAG bridge ready!
HWP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
CRC ERROR! match bit after write is 0 (computed CRC 0x3cef05b8)Retry count exceeded! Abort!

gdb output:
or32-elf-gdb uart.or32
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb (OpenRISC 32-bit toolchain for or32-elf (built 20111122)) 7.2-or32-1.0rc3
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later " target="_blank">http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=or32-elf".
For bug reporting instructions, please see:
..." target="_blank">http://www.opencores.org/>...
Reading symbols from /home/gmessier/ocore/minsoc/sw/uart/uart.or32...done.
(gdb) target remote :9999
Remote debugging using :9999
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb)


I'm definitely a beginner when it comes to FPGA's and I'm doing the verilog mods necessary to get a Spartan 6 FPGA to run with minsoc myself. So, I've gone over my mods very carefully to look for any mistakes but I can't find anything. Specifically, I double checked my modifications to two files:

minsoc_xilinx_internal_jtag.v:
I needed to add an instantiation of the BSCAN_SPARTAN6 module here. I double checked HDL descriptions for BSCAN_SPARTAN6 and the BSCAN_SPARTAN3A that already exists in the file and I think everything's connected correctly.

minsoc_onchip_ram.v:
In this file, I use the existing RAMB16_S9 instantiation for the Spartan 6. The Spartan 6 doesn't have a RAMB16_S9 module but the Xilinx documentation says that the tools supposedly map this code to the correct Spartan 6 module automatically (I don't know if there's problems with this or not, though).

I also tried a self-test with adv_jtag_bridge and got the following output:

./adv_jtag_bridge -b /opt/Xilinx/13.3/ISE_DS/ISE/spartan6/data -t xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC6SLX45_FGG484 0x34008093 6

Target device 0, JTAG ID = 0x34008093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - CPU(s) stalled.
SRAM test:
CRC ERROR! match bit after write is 0 (computed CRC 0xd620d63a)Retry count exceeded! Abort!


So, this seems to indicate that there's enough working to stall the processor but the SRAM test is what's failing here. I'm not sure if that indicates that the BSCAN block is working and the RAM isn't or if there perhaps could still be problems with the BSCAN block.

I've tried all I can think of both on the tools configuration side and checking the sythesis side. Any hints would be greatly appreciated!

Thanks very much for your help!
Geoff

Hi Geoff,

spontaneously I'd say to check if you have POSITIVE_RESET or NEGATIVE_RESET and the value of your CLOCK_DIVISOR on minsoc/backend/minsoc_defines.v

Furthermore, minsoc does not provide specific instantiations for Spartan6 devices. Memory might work well, but FPGA_TAP and FPGA_CLOCK_DIVISION might not.

HTH,
Raul

Thanks for the tip, Raul. I think I'm making some progress.

Using the orpsoc code for the Atlys board as a reference, I established that the reset is negative. That code also indicates that the Spartan 6 can use the DCM_SP instance that's already in the minsoc code for the Spartan 3e and 3a. However, the orpsoc code uses a CLOCK_DIVISOR value of 2 and I was using 4.

When I changed my CLOCK_DIVISOR value to 2, I was able to get a bit further with the adv_jtag_bridge self test. The SRAM test passes now but the program hangs when it tries to restart CPU0. The adv_jtag_bridge output is:

adv_jtag_bridge -b /opt/Xilinx/13.3/ISE_DS/ISE/spartan6/data -t xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC6SLX45_FGG484 0x34008093 6

Target device 0, JTAG ID = 0x34008093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
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!


At which point, it hangs. I'm not clear exactly why I'd be able to stall the CPU and not be able to restart it again. I'll dig into it a bit more but any ideas are very welcome.

Thanks again,
Geoff

Hi Geoff,

I'm glad you're making progress. It would be nice to have a new board as contribution, if you can find the time.

Now I have to know which minsoc version are you using. If you are not using release-1.0, the adv_jtag_bridge self-test simply does not work, in which case you have to disable it (ommit -t). After that, you can already connect with gdb.

Regards,
Raul

I'd definitely like to submit the Atlys changes to minsoc once I have everything up and running. I am using minsoc 1.0 so I guess the -t option should be working. I'll still attempt the direct gdb connect without the -t, though.

I could also post or email you directly with a patch of the verilog changes I've made so far to see if anything jumps out at you. If email is more efficient, we can work that way and then I can post the final solution to the problem in this thread once everything is working.

Thanks very much for your help.
Geoff

Hi Raul,

No luck with skipping the self-test and trying to get gdb working.

adv_jtag_bridge:

> adv_jtag_bridge -b /opt/Xilinx/13.3/ISE_DS/ISE/spartan6/data xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0961 (2401)
cable CPLD version = 0xFFFE (65534)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: XC6SLX45_FGG484 0x34008093 6

Target device 0, JTAG ID = 0x34008093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
JSP server listening on host rex (0.0.0.0), port 9944, address family IPv4
JSP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 0 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 1 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 2 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 3 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 4 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 5 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 6 at startup! 'max retries'
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 7 at startup! 'max retries'
No watchpoint hardware found, HWP server not starting
HWP server listening on host rex (0.0.0.0), port 9928, address family IPv4
JTAG bridge ready!
HWP server thread running!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Burst read timed out.
Retry count exceeded in burst read!
Error while reading all registers: 'max retries'

gdb:
> or32-elf-gdb uart.or32
Building automata... done, num uncovered: 0/216.
Parsing operands data... done.
GNU gdb (OpenRISC 32-bit toolchain for or32-elf (built 20111122)) 7.2-or32-1.0rc3
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later " target="_blank">http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=or32-elf".
For bug reporting instructions, please see:
..." target="_blank">http://www.opencores.org/>...
Reading symbols from /home/gmessier/ocore/minsoc/sw/uart/uart.or32...done.
(gdb) target remote :9999
Remote debugging using :9999
Remote failure reply: E01
(gdb) load
You can't do that when your target is `exec'
(gdb)

I'm assuming that these burst read timeouts and the earlier problems not being able to restart the CPU all point to some problem with my port of the verilog code to the Spartan 6. I'll focus on that but any suggestions would be great.


Geoff

The adv_dbg_if core is not talking to the CPU. It looks like, based on your earlier attempts at the self-test, that the debugger can read and write the SRAM on the WishBone bus just fine. But every attempt to talk to the CPU fails. What's happening in your most recent attempt is that adv_jtag_bridge is trying to read the CPU's DCR registers to see if hardware breakpoints are available, and it's failing to read these registers. This is strange that SRAM works and the CPU does not when using minsoc.

Check that your CPU is connected correctly to the adv_dbg_if, check that the CPU is getting a reset pulse of sufficient duration (it needs a reset pulse before it will work, if memory serves), check the CPU is getting a clock, and check that the CPU memory elements are being synthesized correctly for your FPGA. The problem is most likely somewhere in there.

Thanks for the tips, Nathan. I have it working now. The key was to make the following modifications to or1200_defines.v:
- In the target FPGA memory section, define OR1200_XILINX_RAMB16.
- In the register file RAM section, define OR1200_RFRAM_DUALPORT (not OR1200_RFRAM_GENERIC).

To sum up, my issues were all related to my port of minsoc to the Digilent Atlys board and not with adv_jtag_bridge or or32-elf-gdb. For others hoping to get minsoc running on the Atlys, here's a very brief summary of what I did to get things working (skipping some of the things that will be obvious if you read the minsoc documentation):

1. Create a spartan6_atlys directory as described on the minsoc wiki.
2. In your new spartan6_atlys directory, make the following mods:
- Use xc6slx45-2-csg324 for your device part.
- Modify the ucf file you can download from Digilent using one of the other existing minsoc boards as a reference. Note that the Digilent ucf file uses gigabit GMII ethernet pin connections but minsoc requires 10/100 MII pin connections. The ethernet chip on the Atlys board supports the MII interface so you just need to check out the Atlys reference guide and ethernet chip data sheet to connect the right pins.
- In minsoc_defines.v, create a new device type (I called it SPARTAN6), use FPGA_CLOCK_DIVISION with a divisor of 2 and specify NEGATIVE_RESET.
3. Make the or1200_defines.v modifications I described above.
4. In xilinx_dcm.v, you can allow the SPARTAN6 device to use the XILINX_DCM_SP define but you'll need to specify a value for CLKIN_PERIOD in the DCM_SP module (100 ns).
5. In xilinx_internal_jtag.v, create an instance of the BSCAN_SPARTAN6 module for the SPARTAN6 device.
6. In minsoc_onchip_ram.v, allow the SPARTAN6 device to use the MINSOC_XILINX_RAMB16 define.

With these modifications, adv_jtag_bridge can connect to the board using a xilinx USB jtag cable and the self test completes successfully. I can also upload software using or32-elf-gdb.

I'll also post this information on the following thread:

http://opencores.org/forum,OpenRISC,0,4141

Thanks again to everyone for the help.
Geoff

Hi Geoff,

could we arrange to add your board port to MinSoC? Probably, it would be easiest if you could send your backend directory to us and probably a link to here due to the external changes you mentioned.

We can track the mainstream port process through this email subject.

Regards,
Raul

For sure. I'd like to do a bit more testing on the ethernet and UART hello world examples but once that's done (hopefully by next week), I'll email you directly with my mods. If you think everything looks good, we can perhaps submit it to the SVN server and I can also post a link here.

Geoff

Hi Geoff,

it is really better to provide your port after you run your tests :). Thanks already.



I don't think this was the reason for your errors. I experienced the same error today.

A make clean/make all on minsoc/syn instead of relying on the Makefile dependencies did the job. The Makefile should be ok, at least for most things. I don't really know which old/new dependency was broken.

Raul

My bad, the commands to resolve the dependency were:
make distclean
make all

Raul