2/2 
|
RE: adv_jtag_brigde problem with minsoc
by stoytchostoev on Mar 26, 2012 |
stoytchostoev
Posts: 12 Joined: Oct 18, 2009 Last seen: Apr 3, 2012 |
||
|
Hi Raul,
Thank you for your help. The problem I had was very trivial ( as probably most of the problems, when realized, are ) I have an additional oscillator running on 66MHz on IC16 8pin DIP socket ( comes as default, I have a Spartan 3E board made by Diligent ). Ones removed I it and left the board running on 50MHz, was able to pass the previous problem. Now, just running the self test I get an issue below ( this seems to be described in FAQ as problem with running adv_jtag_bridge on x64 arch ). Not in a self test, am currently getting: `/opt/gdb_stable/bin/or32-elf-gdb uart.or32` ... 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 0x00000024 in ?? () (gdb) I will have to compile for x86, in order to isolate if this is an issues with the arch. ( the self test): `adv_jtag_bridge -t -b. -x3 xpc_usb` Found Xilinx Platform Cable USB (DLC9) Found Xilinx Platform Cable USB (DLC9) XPC USB driver opening cable firmware version = 0x044C (1100) cable CPLD version = 0x0012 (18) Enumerating JTAG chain... Devices on JTAG chain: Index Name ID Code IR Length ---------------------------------------------------------------- 0: xc2c64a_vq44 0x06E5E093 8 1: XCF04S 0xF5046093 8 2: XCF04S 0xF5046093 8 3: XC3S1600E_FG320 0x21C3A093 6 Target device 3, JTAG ID = 0x21c3a093 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! Read npc = 00000010 ppc = 00000028 r1 = 00000005 Expected npc = 00000010 ppc = 00000028 r1 = 00000005 Read npc = 00000028 ppc = 00000028 r1 = 00000008 Expected npc = 00000010 ppc = 00000028 r1 = 00000008 Read npc = 00000024 ppc = 00000020 r1 = 0000000b Expected npc = 00000028 ppc = 00000024 r1 = 0000000b Read npc = 00000020 ppc = 00000020 r1 = 00000018 Expected npc = 00000024 ppc = 00000020 r1 = 00000018 Read npc = 0000001c ppc = 00000018 r1 = 00000031 Expected npc = 00000020 ppc = 0000001c r1 = 00000031 Read npc = 00000020 ppc = 0000001c r1 = 00000032 Expected npc = 00000024 ppc = 00000020 r1 = 00000032 Read npc = 00000010 ppc = 00000028 r1 = 00000063 Expected npc = 00000014 ppc = 00000010 r1 = 00000063 Read npc = 00000010 ppc = 00000028 r1 = 00000063 Expected npc = 00000028 ppc = 00000024 r1 = 00000065 Read npc = 00000010 ppc = 00000028 r1 = 00000094 Expected npc = 00000010 ppc = 00000028 r1 = 000000c9 result = deaddef0 Self-test FAILED *** Bailing out! Regards, Stoev |
|||
|
RE: adv_jtag_brigde problem with minsoc
by stoytchostoev on Mar 26, 2012 |
stoytchostoev
Posts: 12 Joined: Oct 18, 2009 Last seen: Apr 3, 2012 |
||
|
Hi,
adv_jtag_bridge is not passing the self test on 32bit arch: ... 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 = 00000028 ppc = 00000028 r1 = 00000008 Expected npc = 00000010 ppc = 00000028 r1 = 00000008 Read npc = 00000024 ppc = 00000020 r1 = 0000000b Expected npc = 00000028 ppc = 00000024 r1 = 0000000b Read npc = 00000020 ppc = 00000020 r1 = 00000018 Expected npc = 00000024 ppc = 00000020 r1 = 00000018 Read npc = 0000001c ppc = 00000018 r1 = 00000031 Expected npc = 00000020 ppc = 0000001c r1 = 00000031 Read npc = 00000020 ppc = 0000001c r1 = 00000032 Expected npc = 00000024 ppc = 00000020 r1 = 00000032 Read npc = 00000010 ppc = 00000028 r1 = 00000063 Expected npc = 00000014 ppc = 00000010 r1 = 00000063 Read npc = 00000010 ppc = 00000028 r1 = 00000063 Expected npc = 00000028 ppc = 00000024 r1 = 00000065 Read npc = 00000010 ppc = 00000028 r1 = 00000094 Expected npc = 00000010 ppc = 00000028 r1 = 000000c9 result = deaddef0 Self-test FAILED *** Bailing out! |
|||
|
RE: adv_jtag_brigde problem with minsoc
by rfajardo on Mar 26, 2012 |
rfajardo
Posts: 306 Joined: Jun 12, 2008 Last seen: Jan 6, 2020 |
||
|
Hi stoytchostoev,
congratulations, your system already seems to be running correctly. For the development version, it is expected for the self-test to fail exactly as you described. The reason is that minsoc-dev uses the latest processor code for which the self-test is known to fail. http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_self_test_fails (known issues) I basically told you to use minsoc-dev because the adv_jtag_bridge's driver for your cable has been updated recently and did not make into minsoc-1.0. It was basically extremely slow in the past leading to other problems: http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_does_not_connect_to_xpc_usb_why http://www.minsoc.com/advanced_jtag_bridge_faq#adv_jtag_bridge_ignoring_packet_error_continuing_problem However, for the best debugging experience, it would suffice if you use minsoc-1.0 and simply download and compile the latest adv_jtag_bridge yourself. After completing installation os minsoc-1.0 you can proceed like this: cd minsoc/rtl/verilog/adv_debug_sys/Software/adv_jtag_bridge svn update make make install Good luck! Raul |
|||
2/2