Can you edit the exception routine for the trap in or1200_except.v (search for ifdef OR1200_EXCEPT_TRAP) to be:
... epcr <= ex_dslot ? wb_pc : delayed1_ex_dslot ? dl_pc : ex_pc; ... and rerun your tests. If it works, I can download a fresh copy of the source and provide a more general patch. ---Matthew Hicks On Thu, Nov 1, 2012 at 5:19 PM, Franck Jullien <[email protected]> wrote: > 2012/11/1 Stefan Kristiansson <[email protected]>: >> On Tue, Oct 30, 2012 at 09:29:29PM +0100, Marek Czerski wrote: >>> Hello everybody, >>> >>> I'm trying to work with orpsoc branch from >>> http://git.openrisc.net/cgit.cgi/stefan/orpsoc. The issue that i >>> encountered is associated with target debugging through gdb. FPGA project >>> configuration is exactly the same as in repository (fresh git clone) so >>> with adv_debug_sys, altera virtual jtag and onboard usb blaster. When I'm >>> running adv debug bridge i can download the software and run it >>> successfully (done simple bare metal gpio test program written in C). But >>> when i try to stop the target (control^C) i get error in gdb like this: >>> >>> (gdb) target remote :9999 >>> Remote debugging using :9999 >>> 0xf00001a0 in ?? () >>> (gdb) load >>> Loading section .vectors, size 0x2000 lma 0x0 >>> Loading section .init, size 0x28 lma 0x2000 >>> Loading section .text, size 0xe7d8 lma 0x2028 >>> Loading section .fini, size 0x1c lma 0x10800 >>> Loading section .rodata, size 0x66c lma 0x1081c >>> Loading section .eh_frame, size 0x4 lma 0x10e88 >>> Loading section .ctors, size 0xc lma 0x12e8c >>> Loading section .dtors, size 0x8 lma 0x12e98 >>> Loading section .jcr, size 0x4 lma 0x12ea0 >>> Loading section .data, size 0xa04 lma 0x12ea4 >>> Start address 0x2028, load size 71848 >>> Transfer rate: 11 KB/sec, 5526 bytes/write. >>> (gdb) br main >>> Breakpoint 1 at 0x2420: file ../main.c, line 57. >>> (gdb) c >>> Continuing. >>> *Remote failure reply: E01* >>> (gdb) info line >>> *Remote failure reply: E01* >>> (gdb) >>> >>> from adv debug bridge i get: >>> 'usb_blaster' interface using libftdi >>> current latency timer: 2 >>> Enumerating JTAG chain... >>> >>> Devices on JTAG chain: >>> Index Name ID Code IR Length >>> ---------------------------------------------------------------- >>> 0: VIRTUAL_TAP 0x020F30DD 10 >>> >>> Target device 0, JTAG ID = 0x020f30dd >>> JSP server listening on host rozpruwacz (0.0.0.0), port 9944, address >>> family IPv4 >>> JSP server thread running! >>> No watchpoint hardware found, HWP server not starting >>> JTAG bridge ready! >>> CRC ERROR! Computed 0x468e4ec0, read CRC 0x25e00e85 >>> Retry count exceeded! Abort! >>> >>> Error while reading all registers: 'CRC mismatch' >>> CRC ERROR! Computed 0x468e4ec0, read CRC 0x25e00e85 >>> Retry count exceeded! Abort! >>> >>> Error while reading all registers: 'CRC mismatch' >>> >> >> This is a known problem, a (dirty) workaround is to just disable the >> CRC checking: >> >> --->8--- >> Index: Software/adv_jtag_bridge/adv_dbg_commands.c >> =================================================================== >> --- Software/adv_jtag_bridge/adv_dbg_commands.c (revision 57) >> +++ Software/adv_jtag_bridge/adv_dbg_commands.c (working copy) >> @@ -517,6 +517,7 @@ >> >> err |= tap_exit_to_idle(); // Go from EXIT1 to IDLE >> >> +#if 0 >> if(crc_calc != crc_read) { >> printf("CRC ERROR! Computed 0x%x, read CRC 0x%x\n", crc_calc, >> crc_read); >> if(!retry_do()) { >> @@ -526,6 +527,7 @@ >> goto wb_burst_read_retry_full; >> } >> else debug("CRC OK!\n"); >> +#endif >> >> >> // Now, read the error register, and retry/recompute as necessary. >> --->8--- >> >>> With OpenOCD is much better, i can set breakpoints, run, stop, view >>> variables but the problem is with single-stepping. It seems that branch >>> instructions won't single-step. when i execute "step" command in gdb while >>> being on function invocation gdb stops on line after function invocation, >>> not inside the function, without executing the function. Example: >>> (gdb) c >>> Continuing. >>> >>> [Remote target] #1 stopped. >>> main () at ../main.c:65 >>> 65 set_gpio(pin); >>> (gdb) l >>> 60 >>> 61 printf("Hello World !!!\n\r"); >>> 62 >>> 63 for (;;) { >>> 64 >>> 65 set_gpio(pin); >>> 66 >>> 67 printf("pin state: %02x\n\r", gpio_state); >>> 68 >>> 69 msleep(200); >>> (gdb) s >>> 67 printf("pin state: %02x\n\r", gpio_state); >>> (gdb) >>> >>> I'm using trunk version of adv debug bridge from opencores.org svn and >>> OpenOCD from http://git.openrisc.net/cgit.cgi/julius/openocd/ >>> adv_debug_sys<http://git.openrisc.net/cgit.cgi/julius/openocd/log/?h=adv_debug_sys> >>> branch >>> >> >> It's confirmed that there is some problem with the single stepping >> in conjunction with openocd, if you have some more information >> that might give us a hint what's causing this we would appreciate >> it. >> >> Stefan >> _______________________________________________ >> Openrisc mailing list >> [email protected] >> http://lists.opencores.org/listinfo/openrisc > > I think I can see this problem on the simulation. > > What I can see when using the simulation with GDB over VPI (and the > claasic dbg_if) is that the instruction replaced by the TRAP (for sw > breakpoint) never gets executed (see waveform). > So when you break on a branch you can easily see that the branch > didn't get executed...However, if you break on a simple instruction, > you'll never think it didn't get executed and you have no reason to > check if it really did. > > For example: > > 100: 18 60 91 00 l.movhi r3,0x9100 > 104: 9c 80 00 ff l.addi r4,r0,0xff > 108: 18 e0 00 10 l.movhi r7,0x10 > 10c: a8 e7 00 00 l.ori r7,r7,0x0 > 110: 18 c0 11 22 l.movhi r6,0x1122 > 114: 18 c0 00 00 l.movhi r6,0x0 > > I did break at 0x110 and this is what I could see: > > Breakpoint 1, 0x00000110 in ?? () > (gdb) info registers > r0 0x0 0 > r1 0x0 0x0 > r2 0x0 0x0 > r3 0x91000000 2432696320 > r4 0x0 0 > r5 0x0 0 > r6 0x0 0 > > (gdb) stepi > 0x00000114 in ?? () > (gdb) info registers > r0 0x0 0 > r1 0x0 0x0 > r2 0x0 0x0 > r3 0x91000000 2432696320 > r4 0x0 0 > r5 0x0 0 > r6 0x0 0 > > I did the same test on my hardware platform with openOCD + adv_dbg_if > and r6 gets updated.... > However, I can see the bug on branch instructions but I have no way to > debug it on hardware since openOCD and signal tap cannot share the USB > port. > > I don't have much time to work on this so if someone has any idea :) > > Franck. > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
