OpenCores

OpenCores

Minsoc and Altera Cyclone II

no use

no use

1/2

Next

Last

Minsoc and Altera Cyclone II by parrado on Apr 10, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Community, i'm trying to use the Minsoc project under the Cyclone II device included in the DE2-70 board. I'm having problems at compiling time, i'm getting the following Quartus error during analysis: Error: Port "debug_tdo_o" does not exist in macrofunction "tap_top So, i realized that altera_virtual_jtag doesn't have a debug_tdo_o port, instead it has a debug_tdo_i port, so i changed the pin used at minsoc_top to debug_tdo_i port. After this, project compiles without errors. Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting. I have read several times documentation and i can't see any error on my design. So i wrote you asking for some help with this issue. Best regards, Alexander Hi Community, i'm trying to use the Minsoc project under the Cyclone II device included in the DE2-70 board. I'm having problems at compiling time, i'm getting the following Quartus error during analysis: Error: Port "debug_tdo_o" does not exist in macrofunction "tap_top So, i realized that altera_virtual_jtag doesn't have a debug_tdo_o port, instead it has a debug_tdo_i port, so i changed the pin used at minsoc_top to debug_tdo_i port. After this, project compiles without errors. Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting. I have read several times documentation and i can't see any error on my design. So i wrote you asking for some help with this issue. Best regards, Alexander

RE: Minsoc and Altera Cyclone II by rfajardo on Apr 10, 2010			rfajardo Posts: 306 Joined: Jun 12, 2008 Last seen: Jan 6, 2020
Hi Alexander, [q]I'm having problems at compiling time, i'm getting the following Quartus error during analysis: Error: Port "debug_tdo_o" does not exist in macrofunction "tap_top So, i realized that altera_virtual_jtag doesn't have a debug_tdo_o port, instead it has a debug_tdo_i port, so i changed the pin used at minsoc_top to debug_tdo_i port. After this, project compiles without errors.[/q] That is a bug, that signal changed on altera_virtual_jtag.vhd on version 34 of the Advanced Debug System. I missed that change, therefore is minsoc still outdated. Since I don't use the Altera chips I didn't notice it. Your workaround should solve the issue. [q]Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting.[/q] This is for now, some issue with your cable and the adv_jtag_bridge, I'm not certain of what exactly. Nathan, the creator of the Advanced Debug System might know better about that. From the USB error report, it seems your device is simply busy or full, maybe taken by some other program. I would close all other programs which control the cable, Quartus or similar and reconnect the cable, then try again. If that doesn't work I still had some hints, on things you could check/test. 1. Try to change your USB cable set used by the adv_jtag_bridge to a ftdi based one. I quote: [q]# Some users have reported failures with the standard libusb-based USBBlaster # driver, but success using a libftdi-based driver. Set this 'true' to use # this libftdi-based driver. Do not use except as a last resort - this driver # does not use the USB-Blaster's high speed transfer mode, making it very slow. # SUPPORT_FTDI_CABLES must also be set 'true' to use this driver. USE_ALT_FTDI_USBBLASTER_DRIVER=false[/q] So take a look into your adv_jtag_bridge Makefile, change it accordingly and try again. Make sure you didn't turn on SUPPORT_LEGACY for example. You could also try to set USE_HIGHSPEED to false, however this is certainly not your problem. 2. Downgrade your Advanced Debug System, resynthesize and place&route your design, recompile adv_jtag_bridge and give it a second try. To downgrade, from minsoc/rtl/verilog/adv_debug_sys/: $ svn update -r 35 3. The Advanced Debug System has been newly updated and I have updated the howto documentation accordingly but only like 3 days ago. This guides you to do 2 things (take a look if you did it): -change the Makefile of adv_jtag_bridge not to include the JSP server, line 34 to INCLUDE_JSP_SERVER=false. Recompile. -comment out line 67 `define DBG_JSP_SUPPORTED of minsoc/rtl/verilog/adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v 4. Try instead of the altera tap the generic tap. You will need to set external pins of your board to be the jtag connection (header), do that including them in a ucf file, resynthesize and P&R. Connect your usbblaster on these pins, instead of on JTAG header to configure the FPGA. Run adv_jtag_bridge again. Best regards and good luck, Raul Hi Alexander, I'm having problems at compiling time, i'm getting the following Quartus error during analysis: Error: Port "debug_tdo_o" does not exist in macrofunction "tap_top So, i realized that altera_virtual_jtag doesn't have a debug_tdo_o port, instead it has a debug_tdo_i port, so i changed the pin used at minsoc_top to debug_tdo_i port. After this, project compiles without errors. That is a bug, that signal changed on altera_virtual_jtag.vhd on version 34 of the Advanced Debug System. I missed that change, therefore is minsoc still outdated. Since I don't use the Altera chips I didn't notice it. Your workaround should solve the issue. Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting. This is for now, some issue with your cable and the adv_jtag_bridge, I'm not certain of what exactly. Nathan, the creator of the Advanced Debug System might know better about that. From the USB error report, it seems your device is simply busy or full, maybe taken by some other program. I would close all other programs which control the cable, Quartus or similar and reconnect the cable, then try again. If that doesn't work I still had some hints, on things you could check/test. 1. Try to change your USB cable set used by the adv_jtag_bridge to a ftdi based one. I quote: # Some users have reported failures with the standard libusb-based USBBlaster # driver, but success using a libftdi-based driver. Set this 'true' to use # this libftdi-based driver. Do not use except as a last resort - this driver # does not use the USB-Blaster's high speed transfer mode, making it very slow. # SUPPORT_FTDI_CABLES must also be set 'true' to use this driver. USE_ALT_FTDI_USBBLASTER_DRIVER=false So take a look into your adv_jtag_bridge Makefile, change it accordingly and try again. Make sure you didn't turn on SUPPORT_LEGACY for example. You could also try to set USE_HIGHSPEED to false, however this is certainly not your problem. 2. Downgrade your Advanced Debug System, resynthesize and place&route your design, recompile adv_jtag_bridge and give it a second try. To downgrade, from minsoc/rtl/verilog/adv_debug_sys/: $ svn update -r 35 3. The Advanced Debug System has been newly updated and I have updated the howto documentation accordingly but only like 3 days ago. This guides you to do 2 things (take a look if you did it): -change the Makefile of adv_jtag_bridge not to include the JSP server, line 34 to INCLUDE_JSP_SERVER=false. Recompile. -comment out line 67 `define DBG_JSP_SUPPORTED of minsoc/rtl/verilog/adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v 4. Try instead of the altera tap the generic tap. You will need to set external pins of your board to be the jtag connection (header), do that including them in a ucf file, resynthesize and P&R. Connect your usbblaster on these pins, instead of on JTAG header to configure the FPGA. Run adv_jtag_bridge again. Best regards and good luck, Raul

RE: Minsoc and Altera Cyclone II by nyawn on Apr 10, 2010			nyawn Posts: 173 Joined: Dec 19, 2008 Last seen: May 31, 2023
[q] Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting. [/q] This is an error I have not seen before. It's odd that the driver succeeds in doing a USB 'control' transaction to get the firmware version from the cable, but then fails to do a bulk data transaction to actually access the JTAG interface. The problem here is definitely between the USB-Blaster cable and driver, and has nothing to do with the FPGA configuration. Using the stand-alone TAP won't change anything, nor will downgrading the advanced debug system version. You may try unplugging the USB-Blaster from your PC after downloading the bitstream to the FPGA, but before starting adv_jtag_bridge. If the programming utility left the cable in a strange state, this will probably fix it. Unfortunately, it's also possible that it's a new and different type of USB Blaster, with a slightly different protocol. In this case, your best chance is to edit the adv_jtag_bridge Makefile to use the alternate USB-Blaster driver. This is, unfortunately, much slower. Let me know if does or doesn't work, I'm very interested in the outcome. Nathan Yawn Further, after FPGA programming using USBLASTER, when i executed adv_jtag_bridge usbblaster i got following messages: Found Altera USB-Blaster Found Altera USB-Blaster firmware version = 0x0004 (4) Enumerating JTAG chain... Failed to write to the FIFO (rv = -110): No error Failed to write a read request to the EP2 FIFO: No errorError 'USB' enumerating JTAG chain, aborting. This is an error I have not seen before. It's odd that the driver succeeds in doing a USB 'control' transaction to get the firmware version from the cable, but then fails to do a bulk data transaction to actually access the JTAG interface. The problem here is definitely between the USB-Blaster cable and driver, and has nothing to do with the FPGA configuration. Using the stand-alone TAP won't change anything, nor will downgrading the advanced debug system version. You may try unplugging the USB-Blaster from your PC after downloading the bitstream to the FPGA, but before starting adv_jtag_bridge. If the programming utility left the cable in a strange state, this will probably fix it. Unfortunately, it's also possible that it's a new and different type of USB Blaster, with a slightly different protocol. In this case, your best chance is to edit the adv_jtag_bridge Makefile to use the alternate USB-Blaster driver. This is, unfortunately, much slower. Let me know if does or doesn't work, I'm very interested in the outcome. Nathan Yawn

RE: Minsoc and Altera Cyclone II by parrado on Apr 11, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Nathan thanks for your answer, Unplugging and plugging again usbblaster didn't solve issue. For compiling adv_jtag_bridge in fdti mode for USBBLASTER, it was needed manual compiling of libftdi-0.14 on my Ubuntu 8.04 machine, repositories library is too old (libftdi-0.10). Further, EP2C70F896.BSD file downloaded from Altera site was copied to /usr/local/bin. After theese steps, following messages apeared when running adv_jtag_bridge: adv_jtag_bridge usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd IDCODE sanity test passed, chain OK! JSP server listening on host parrado-laptop (::), port 9944, address family IPv6 JSP server thread running! JTAG bridge ready! It seems has worked. I'll follow with software part. Hi Nathan thanks for your answer, Unplugging and plugging again usbblaster didn't solve issue. For compiling adv_jtag_bridge in fdti mode for USBBLASTER, it was needed manual compiling of libftdi-0.14 on my Ubuntu 8.04 machine, repositories library is too old (libftdi-0.10). Further, EP2C70F896.BSD file downloaded from Altera site was copied to /usr/local/bin. After theese steps, following messages apeared when running adv_jtag_bridge: adv_jtag_bridge usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd IDCODE sanity test passed, chain OK! JSP server listening on host parrado-laptop (::), port 9944, address family IPv6 JSP server thread running! JTAG bridge ready! It seems has worked. I'll follow with software part.

RE: Minsoc and Altera Cyclone II by rfajardo on Apr 11, 2010			rfajardo Posts: 306 Joined: Jun 12, 2008 Last seen: Jan 6, 2020
Hi Alexander, great news, I'm glad it worked with the libftdi based cable. I wanted to explain to you that minsoc has not been based, doesn't explain the usage of the JSP (JTAG Serial Port). JSP is a new addition to the Advanced Debug System, it emulates a serial port through the JTAG interface, besides of the use of JTAG debugigng over it. Since I didn't have time to try it out, I added to the minsoc howto an explanation of how to turn it off, but you probably got an older version of the howto, it has only been updated in the last days. So, unless you want to try out this feature by yourself (Advanced Debug System documenation will definitely help you there), you should do these 2 steps to remove it from your system: -change the Makefile of adv_jtag_bridge not to include the JSP server, line 34 to INCLUDE_JSP_SERVER=false. Recompile. -comment out line 67 `define DBG_JSP_SUPPORTED of minsoc/rtl/verilog/adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v . Resynthesize, Place&Route, configure FPGA. So, you are ready to go, I hope you have fun and can use OpenRISC for your needs. Regards, Raul Hi Alexander, great news, I'm glad it worked with the libftdi based cable. I wanted to explain to you that minsoc has not been based, doesn't explain the usage of the JSP (JTAG Serial Port). JSP is a new addition to the Advanced Debug System, it emulates a serial port through the JTAG interface, besides of the use of JTAG debugigng over it. Since I didn't have time to try it out, I added to the minsoc howto an explanation of how to turn it off, but you probably got an older version of the howto, it has only been updated in the last days. So, unless you want to try out this feature by yourself (Advanced Debug System documenation will definitely help you there), you should do these 2 steps to remove it from your system: -change the Makefile of adv_jtag_bridge not to include the JSP server, line 34 to INCLUDE_JSP_SERVER=false. Recompile. -comment out line 67 `define DBG_JSP_SUPPORTED of minsoc/rtl/verilog/adv_debug_sys/Hardware/adv_dbg_if/rtl/verilog/adbg_defines.v . Resynthesize, Place&Route, configure FPGA. So, you are ready to go, I hope you have fun and can use OpenRISC for your needs. Regards, Raul

RE: Minsoc and Altera Cyclone II by parrado on Apr 11, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi, Raul thanks for your answers and suggestions, I took them into account: Now, i'm testing the software part with de uart example as explained in "how to". Again, i'm getting in trouble, now with GDB. Having running adv_jtag_bridge in its own terminal and running gdb, I'm getting this output: or32-elf-gdb uart-nocache.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 <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=i686-pc-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 Ignoring packet error, continuing... Loading section .vectors, size 0xe1c lma 0x200 Ignoring packet error, continuing... Loading section .text, size 0x23dc lma 0x1200 Ignoring packet error, continuing... Loading section .rodata, size 0x42 lma 0x35dc Ignoring packet error, continuing... Loading section .data, size 0x34 lma 0x3620 Ignoring packet error, continuing... Start address 0x1200, load size 13310 Transfer rate: 243 bytes/sec, 2662 bytes/write. (gdb) set $pc=0x100 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... And in the adv_jtag_bridge terminal following messages are showed: Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Guys, now what can I do? I'll appreciate all you suggestions, thanks again. Alex Hi, Raul thanks for your answers and suggestions, I took them into account: Now, i'm testing the software part with de uart example as explained in "how to". Again, i'm getting in trouble, now with GDB. Having running adv_jtag_bridge in its own terminal and running gdb, I'm getting this output: or32-elf-gdb uart-nocache.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=i686-pc-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 Ignoring packet error, continuing... Loading section .vectors, size 0xe1c lma 0x200 Ignoring packet error, continuing... Loading section .text, size 0x23dc lma 0x1200 Ignoring packet error, continuing... Loading section .rodata, size 0x42 lma 0x35dc Ignoring packet error, continuing... Loading section .data, size 0x34 lma 0x3620 Ignoring packet error, continuing... Start address 0x1200, load size 13310 Transfer rate: 243 bytes/sec, 2662 bytes/write. (gdb) set $pc=0x100 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... And in the adv_jtag_bridge terminal following messages are showed: Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Guys, now what can I do? I'll appreciate all you suggestions, thanks again. Alex

RE: Minsoc and Altera Cyclone II by nyawn on Apr 11, 2010			nyawn Posts: 173 Joined: Dec 19, 2008 Last seen: May 31, 2023
If you're seeing the JTAG chain enumeration, that means your previous problem is fixed, and the adv_jtag_bridge driver is talking to the cable correctly. Try running the self-test (pass the -t argument to adv_jtag_bridge) and see if it passes. The only time I've seen GDB give "Ignoring packet error, continuing" is when a transaction is taking a very long time. 500-600 bytes/sec is usually fast enough, but it looks like yours is moving slower than that. But, I don't have any hard numbers on how slow is 'too slow,' and I don't know GDB well enough to tell you exactly what that error means. It is surprising that the packet error message shows up so many times on a simple command like "set $pc=0x100". How long did you wait for it to complete? The warnings from adv_jtag_bridge ("Warning: async break received while target stopped") means that you probably pressed Control-C in GDB, and it passed the break/stop command along to adv_jtag_bridge. But, the CPU on the FPGA was already stopped, so it did nothing and printed the warning. If you're seeing the JTAG chain enumeration, that means your previous problem is fixed, and the adv_jtag_bridge driver is talking to the cable correctly. Try running the self-test (pass the -t argument to adv_jtag_bridge) and see if it passes. The only time I've seen GDB give "Ignoring packet error, continuing" is when a transaction is taking a very long time. 500-600 bytes/sec is usually fast enough, but it looks like yours is moving slower than that. But, I don't have any hard numbers on how slow is 'too slow,' and I don't know GDB well enough to tell you exactly what that error means. It is surprising that the packet error message shows up so many times on a simple command like "set $pc=0x100". How long did you wait for it to complete? The warnings from adv_jtag_bridge ("Warning: async break received while target stopped") means that you probably pressed Control-C in GDB, and it passed the break/stop command along to adv_jtag_bridge. But, the CPU on the FPGA was already stopped, so it did nothing and printed the warning.

RE: Minsoc and Altera Cyclone II by rfajardo on Apr 11, 2010			rfajardo Posts: 306 Joined: Jun 12, 2008 Last seen: Jan 6, 2020
I only wanted to add, that funny enough gdb reported that same: Ignoring packet error, continuing... even when the adv_jtag_bridge was not sending or receiving any data at all (older mutex lock problems). Regards, Raul I only wanted to add, that funny enough gdb reported that same: Ignoring packet error, continuing... even when the adv_jtag_bridge was not sending or receiving any data at all (older mutex lock problems). Regards, Raul

RE: Minsoc and Altera Cyclone II by parrado on Apr 12, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Guys, thanks for your answers and disposition. After setting PC, following messages are showed during, say, 30 seconds. After this interval, automatically "Quit" message appears, Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... After "Quit" message on GDB this message is showed on adv_jtag_bridge. I didn't issue a ctrl+c command. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Finally, it seems self-test is passed acording the following messages: adv_jtag_bridge -t usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd 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 * JTAG bridge ready! So, what the next step? I'll appreciate any help in this topic. Best regards, Alex Hi Guys, thanks for your answers and disposition. After setting PC, following messages are showed during, say, 30 seconds. After this interval, automatically "Quit" message appears, Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... After "Quit" message on GDB this message is showed on adv_jtag_bridge. I didn't issue a ctrl+c command. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Finally, it seems self-test is passed acording the following messages: adv_jtag_bridge -t usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd 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 * JTAG bridge ready! So, what the next step? I'll appreciate any help in this topic. Best regards, Alex

RE: Minsoc and Altera Cyclone II by parrado on Apr 12, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Guys, thanks for your answers and disposition. After setting PC, following messages are showed during, say, 30 seconds. After this interval, automatically "Quit" message appears, Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... After "Quit" message on GDB this message is showed on adv_jtag_bridge. I didn't issue a ctrl+c command. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Finally, it seems self-test is passed acording the following messages: adv_jtag_bridge -t usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd 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 * JTAG bridge ready! So, what is the next step? I'll appreciate any help in this topic. Best regards, Alex Hi Guys, thanks for your answers and disposition. After setting PC, following messages are showed during, say, 30 seconds. After this interval, automatically "Quit" message appears, Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... After "Quit" message on GDB this message is showed on adv_jtag_bridge. I didn't issue a ctrl+c command. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Warning: asynchronous BREAK received while target stopped. Finally, it seems self-test is passed acording the following messages: adv_jtag_bridge -t usbblaster 'usb_blaster' interface using libftdi current latency timer: 2 Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: EP2C70F896 0x020B60DD 10 Target device 0, JTAG ID = 0x020b60dd 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 * JTAG bridge ready! So, what is the next step? I'll appreciate any help in this topic. Best regards, Alex

RE: Minsoc and Altera Cyclone II by nyawn on Apr 12, 2010			nyawn Posts: 173 Joined: Dec 19, 2008 Last seen: May 31, 2023
Hm, the self-test passes. This means that 1. The debug hardware is attached correctly to the bus, 2. The debug hardware is attached correctly to the OR1200, 3. The OR1200 is attached correctly to the memory at address 0x0, and 4. adv_jtag_bridge is communicating correctly with the debug hardware, the OR1200, and the WishBone bus. This is all good. So, it seems the problem is actually between GDB and adv_jtag_bridge. I'm still suspecting a speed issue, like maybe adv_jtag_bridge isn't able to complete a transaction by the time GDB gives up and goes on to the next one. You might test this by enabling debug in rsp-server.c (change the value of "#define RSP_TRACE 0" to 1), then see if the debug output of adv_jtag_bridge tracks with what GDB is doing, or if it lags behind. (Though really, this may not be all that useful, it may be hard to tell). I did make one recent change I can think of that might affect this...near the top of rsp-server.c, I increased the size of GDB_BUF_MAX, which controls the maximum size of a packet that GDB will send. If you make this smaller, then I think GDB will send less data at a time, but will still wait just as long for the transaction to complete, which could help/fix the problem if it's really just that the libftdi usb-blaster driver can't keep up. Change GDB_BUF_MAX back to it's original value of (NUM_REGS8)+1, and see if that helps. Hm, the self-test passes. This means that 1. The debug hardware is attached correctly to the bus, 2. The debug hardware is attached correctly to the OR1200, 3. The OR1200 is attached correctly to the memory at address 0x0, and 4. adv_jtag_bridge is communicating correctly with the debug hardware, the OR1200, and the WishBone bus. This is all good. So, it seems the problem is actually between GDB and adv_jtag_bridge. I'm still suspecting a speed issue, like maybe adv_jtag_bridge isn't able to complete a transaction by the time GDB gives up and goes on to the next one. You might test this by enabling debug in rsp-server.c (change the value of "#define RSP_TRACE 0" to 1), then see if the debug output of adv_jtag_bridge tracks with what GDB is doing, or if it lags behind. (Though really, this may not be all that useful, it may be hard to tell). I did make one recent change I can think of that might affect this...near the top of rsp-server.c, I increased the size of GDB_BUF_MAX, which controls the maximum size of a packet that GDB will send. If you make this smaller, then I think GDB will send less data at a time, but will still wait just as long for the transaction to complete, which could help/fix the problem if it's really just that the libftdi usb-blaster driver can't keep up. Change GDB_BUF_MAX back to it's original value of (NUM_REGS8)+1, and see if that helps.

RE: Minsoc and Altera Cyclone II by parrado on Apr 13, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Nathan, Your workaround has solved the issue, thanks a lot. Now i'm testing on Cyclone II and Stratix ii devices without problems. However, it's frustrating the extremely slow speed of the FTDI mode for adv_jtag_bridge, it'll be useful to use the normal mode, not the FTDI one. There is a way to solve this bottleneck?. If it can't be done, a Linux image download could become a nightmare. Best regards, and again thanks a lot for your help and disposition. Alex. Hi Nathan, Your workaround has solved the issue, thanks a lot. Now i'm testing on Cyclone II and Stratix ii devices without problems. However, it's frustrating the extremely slow speed of the FTDI mode for adv_jtag_bridge, it'll be useful to use the normal mode, not the FTDI one. There is a way to solve this bottleneck?. If it can't be done, a Linux image download could become a nightmare. Best regards, and again thanks a lot for your help and disposition. Alex.

RE: Minsoc and Altera Cyclone II by rfajardo on Apr 13, 2010			rfajardo Posts: 306 Joined: Jun 12, 2008 Last seen: Jan 6, 2020
Hi Alex, I suppose I can inform users of MinSoC the StratixII platform has been tested and is working, right? Something I've been asking for are the ucf files for the different boards, the standard MinSoC is effectively implemented on. That might help users even further on using the system. In case anyone would like to contribute I'd be very happy. You could drop me an email. You don't have to naturally. I hope the system fits you and you have fun, Raul Hi Alex, I suppose I can inform users of MinSoC the StratixII platform has been tested and is working, right? Something I've been asking for are the ucf files for the different boards, the standard MinSoC is effectively implemented on. That might help users even further on using the system. In case anyone would like to contribute I'd be very happy. You could drop me an email. You don't have to naturally. I hope the system fits you and you have fun, Raul

RE: Minsoc and Altera Cyclone II by parrado on Apr 13, 2010			parrado Posts: 19 Joined: Jul 16, 2008 Last seen: Nov 12, 2020
Hi Raul, In fact, cores tested on my Stratix ii are just: OpenRISC1200, Onchip RAM, JTAG and Advanced Debug Interface. However, i guess it can be informed to community the successful tests of MinSoC on Stratix II devices. Hi Raul, In fact, cores tested on my Stratix ii are just: OpenRISC1200, Onchip RAM, JTAG and Advanced Debug Interface. However, i guess it can be informed to community the successful tests of MinSoC on Stratix II devices.

RE: Minsoc and Altera Cyclone II by nyawn on Apr 13, 2010			nyawn Posts: 173 Joined: Dec 19, 2008 Last seen: May 31, 2023
[q]Hi Nathan, Your workaround has solved the issue, thanks a lot. Now i'm testing on Cyclone II and Stratix ii devices without problems. However, it's frustrating the extremely slow speed of the FTDI mode for adv_jtag_bridge, it'll be useful to use the normal mode, not the FTDI one. There is a way to solve this bottleneck?. If it can't be done, a Linux image download could become a nightmare. [/q] I'm glad this got you up and running, at least. I'll add Stratix II to my list of tested devices! I don't know of any direct way to make my high-speed USB-Blaster driver work with your cable...this is the second report of problems with my driver, so I'm assuming there are different versions of the USB-Blaster cable with some slight differences that make them incompatible with my driver. But, I don't have one of these incompatible cables, and even if I did, I don't have a USB protocol analyzer to try to find the differences. However, it may be possible to add high-speed support to the FT245 driver. The FT245 driver was donated to my project (I didn't write it), but I seem to remember looking through it thinking it would be straightforward to adapt the high-speed routines from my USB-Blaster driver to work with libftdi. I simply haven't taken the time to try it yet (and I couldn't properly test it even if I did). You could try it yourself, if you were so inclined...if it works, I'd be happy to add it to the adv_debug_sys project. Hi Nathan, Your workaround has solved the issue, thanks a lot. Now i'm testing on Cyclone II and Stratix ii devices without problems. However, it's frustrating the extremely slow speed of the FTDI mode for adv_jtag_bridge, it'll be useful to use the normal mode, not the FTDI one. There is a way to solve this bottleneck?. If it can't be done, a Linux image download could become a nightmare. I'm glad this got you up and running, at least. I'll add Stratix II to my list of tested devices! I don't know of any direct way to make my high-speed USB-Blaster driver work with your cable...this is the second report of problems with my driver, so I'm assuming there are different versions of the USB-Blaster cable with some slight differences that make them incompatible with my driver. But, I don't have one of these incompatible cables, and even if I did, I don't have a USB protocol analyzer to try to find the differences. However, it may be possible to add high-speed support to the FT245 driver. The FT245 driver was donated to my project (I didn't write it), but I seem to remember looking through it thinking it would be straightforward to adapt the high-speed routines from my USB-Blaster driver to work with libftdi. I simply haven't taken the time to try it yet (and I couldn't properly test it even if I did). You could try it yourself, if you were so inclined...if it works, I'd be happy to add it to the adv_debug_sys project.

no use

no use

1/2

Next

Last

© copyright 1999-2024 OpenCores.org, equivalent to Oliscience, all rights reserved. OpenCores®, registered trademark.