1/1

|
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. |
|||
1/1

