OpenCores
no use no use 1/1 no use no use
Problems debugging and uploading minsoc
by benderz on Dec 10, 2011
benderz
Posts: 4
Joined: Feb 21, 2011
Last seen: Jun 1, 2012
Hello everybody!

I am trying to upload & debug minsoc in a Spartan-3E Starter Kit but I can't by now.
I followed the tutorial at the webpage but I think I am doing something wrong.

What I get is always a CRC Problem:

parallels@ubuntu:~$ adv_jtag_bridge -x2 xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0404 (1028)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: xc2c64a 0x06E5E093 8
1: XCF04S 0xF5046093 8
2: XC3S500E_FG320 0x41C22093 6

Target device 2, JTAG ID = 0x41c22093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 0 at startup! 'max retries'
Burst read timed out.


I searched all over the forum and the internet but I didn't find the answer.
While following the tutorial, in the Synthesis chapter, point 6 says Synthesize, P&R and upload bit file but just next to this there is a link for software upload and debugging so I do not get if should I upload the bit file with the ISE Xilinx or just following the next chapter. Doing the second I get what I posted before, doing the first all I get is this:

(...)
1023: (unknown) 0xFFFFFFFF -1

Target device 2, JTAG ID = 0xffffffff
ERROR! Unable to autoprobe IR length for device index 2; Must set IR size on command line. Aborting.

It is nonsense for me.
If I perform the self-test this is what I get:

Target device 2, JTAG ID = 0x41c22093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - or1k is not stalled!
Self-test FAILED *** Bailing out!


I tried to synthesize with ISE (including the whole project) and with the scripts within minsoc/syn with a "make all".
I don't know what to do now. I would appreciate any help.

Thank you very much in advance.

Daniel
RE: Problems debugging and uploading minsoc
by rfajardo on Dec 10, 2011
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
Hi Daniel,

What I get is always a CRC Problem:

parallels@ubuntu:~$ adv_jtag_bridge -x2 xpc_usb
Found Xilinx Platform Cable USB (DLC9)
Found Xilinx Platform Cable USB (DLC9)
firmware version = 0x0404 (1028)
cable CPLD version = 0x0012 (18)
Enumerating JTAG chain...

Devices on JTAG chain:
Index Name ID Code IR Length
----------------------------------------------------------------
0: xc2c64a 0x06E5E093 8
1: XCF04S 0xF5046093 8
2: XC3S500E_FG320 0x41C22093 6

Target device 2, JTAG ID = 0x41c22093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
Burst read timed out.
Retry count exceeded in burst read!
ERROR reading DCR 0 at startup! 'max retries'
Burst read timed out.


I searched all over the forum and the internet but I didn't find the answer.
While following the tutorial, in the Synthesis chapter, point 6 says Synthesize, P&R and upload bit file but just next to this there is a link for software upload and debugging so I do not get if should I upload the bit file with the ISE Xilinx or just following the next chapter.


I don't know exactly which instructions were you following and which page was that. But I have seen that the release-1.0 synthesis page does not say to upload the bitfile. You have to do it before proceeding to software upload and debug. Upload the bitfile using Impact.

Doing the second I get what I posted before, doing the first all I get is this:

(...)
1023: (unknown) 0xFFFFFFFF -1

Target device 2, JTAG ID = 0xffffffff
ERROR! Unable to autoprobe IR length for device index 2; Must set IR size on command line. Aborting.

It is nonsense for me.
If I perform the self-test this is what I get:

Target device 2, JTAG ID = 0x41c22093
Xilinx IDCODE, assuming internal BSCAN mode
(using USER1 instead of DEBUG TAP command)
IDCODE sanity test passed, chain OK!
*** Doing self-test ***
Stall or1k - or1k is not stalled!
Self-test FAILED *** Bailing out!


I tried to synthesize with ISE (including the whole project) and with the scripts within minsoc/syn with a "make all".l


Your problem is very probably that you use the DLC9 cable or xpc_usb cable. After uploading the bitfile, the USB cable is put into a mode which is not usable by adv_jtag_bridge.

There are a handful of options. Check the Advanced Debug System FAQ on MinSoC Wiki.
http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_does_not_connect_to_my_cable_why
Example 2 is related to this problem.

I hope that helps,
Raul
RE: Problems debugging and uploading minsoc
by benderz on Dec 10, 2011
benderz
Posts: 4
Joined: Feb 21, 2011
Last seen: Jun 1, 2012
Hi Raul, thank you very much for your reply!

The problem was indeed that and I solved the same way. I read that part of the FAQ before but I don't know why I let it go as it wasn't my problem. Thanks again.

Now, I am available to start the server and connect to it through gdb but when it comes to set the $pc=0x100 it gets into an infinite loop or that's what it seems. Since I launch the command set $pc=0x100 I just get "Ignoring packet error, continuing..." over and over again and finally I have to terminate the process.
The command sequence I use for gdb is the one listed in the minsoc tutorial:
or32-elf-gdb uart.or32
target remote :9999 (first I do set remotetimeout 10)
load
set $pc=0x100

BTW is it normal that every step/command takes several minutes to be completed?

Thanks again,

Daniel.
RE: Problems debugging and uploading minsoc
by rfajardo on Dec 11, 2011
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
The support for your cable is not good. Therefore, everything takes time.

You could check this for some possibilities about the ignoring packet issue:
http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_ignoring_packet_error_continuing_problem

But it will not make it faster.

Either someone with knowledge about the internals of the cable would have to write a new driver or someone would write both a firmware for the cable's FX2 chip and an adapted driver for the adv_jtag_bridge.

You could also try to grab another JTAG cable with better support. If your USB cable is built onboard, you would have to use the generic JTAG TAP and assign pins for the JTAG signals to which you connect the cable. If your USB cable is not onboard and the JTAG of the FPGA is available to be connected to, you can simply replace the cable.

That's a pity, but this cable's specs are not available so the implementation has struggled to be finished.

Good luck,
Raul
RE: Problems debugging and uploading minsoc
by benderz on Dec 14, 2011
benderz
Posts: 4
Joined: Feb 21, 2011
Last seen: Jun 1, 2012
Thanks again Raul, I have been trying everything I have found with no results at all.

I have another question. Is this the only way to upload software be executed in the OR processor? I mean, using gdb and load command (that is for upload software, right?) Because may be I could just upload in other way and once it is executing debug my software using the UART interface reading from another program in my computer.

I use a USB-RS232 cable so it is not in the usual device /dev/ttyS0, in my case it is /dev/USB0. Should I change this somewhere?

Thanks,

Daniel.
RE: Problems debugging and uploading minsoc
by benderz on Dec 14, 2011
benderz
Posts: 4
Joined: Feb 21, 2011
Last seen: Jun 1, 2012
Thanks again Raul, I have been trying everything I have found with no results at all.

I have another question. Is this the only way to upload software be executed in the OR processor? I mean, using gdb and load command (that is for upload software, right?) Because may be I could just upload in other way and once it is executing debug my software using the UART interface reading from another program in my computer.

I use a USB-RS232 cable so it is not in the usual device /dev/ttyS0, in my case it is /dev/USB0. Should I change this somewhere?

Thanks,

Daniel.
RE: Problems debugging and uploading minsoc
by rfajardo on Dec 16, 2011
rfajardo
Posts: 306
Joined: Jun 12, 2008
Last seen: Jan 6, 2020
Hi Daniel,

I have another question. Is this the only way to upload software be executed in the OR processor? I mean, using gdb and load command (that is for upload software, right?) Because may be I could just upload in other way and once it is executing debug my software using the UART interface reading from another program in my computer.


There are some options described in the following link.
http://www.minsoc.com/minsoc_faq#i_want_my_design_to_automatically_initialize_my_firmware_on_power-up_how_do_i_do_that

There are other options, but no one has bothered to do anything about it. Either you support the cable better, as described earlier, or you could write a bootloader for another interface and put it together on the start-up code of the BRAMs, so you can bootstrap firmware from another interface. I've heard u-boot has been used lately for that purpose on orpsoc.

I use a USB-RS232 cable so it is not in the usual device /dev/ttyS0, in my case it is /dev/USB0. Should I change this somewhere?


Later, when the firmware is already on the device, you will open a gtkterm (or another terminal program) for communicating with the firmware. There, you have to go to Configuration->Port and select /dev/ttyUSB0 or so, and also the speed, probably 115200.
no use no use 1/1 no use no use
© copyright 1999-2026 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.