2012/11/20 Matthew Hicks <[email protected]>: > Please file a bug so there is a record of what changes have been made > to the processor. The open list of bugs has been vital to my research > and the main reason why I selected OR1200 over Leon3. > > > ---Matthew Hicks > > > On Tue, Nov 20, 2012 at 3:22 PM, Franck Jullien > <[email protected]> wrote: >> ---------- Forwarded message ---------- >> From: Franck Jullien <[email protected]> >> Date: 2012/11/3 >> Subject: Re: [OpenRISC] [Openrisc] Problems with debbuging on de0_nano board >> To: Marek Czerski <[email protected]> >> Cc : Matthew Hicks <[email protected]>, >> [email protected], [email protected] >> >> >> 2012/11/3 Franck Jullien <[email protected]>: >>> 2012/11/2 Marek Czerski <[email protected]>: >>>>> This is a known problem, a (dirty) workaround is to just disable the >>>>> CRC checking: >>>> >>>> ok, it helped. >>>> >>>>> >> 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). >>>> >>>> >>>> I can confirm this behavior both in simulation (dbg_if + VPI) and on >>>> hardware with adv_dbg_if + adv_jtag_bridge. >>>> >>>>> >>>>> >> I did the same test on my hardware platform with openOCD + adv_dbg_if >>>>> >> and r6 gets updated.... >>>> >>>> >>>> With adv_dbg_if + OpneOCD it works as Franck said. >>>> >>>> It seems that the issue is related with the software since adv_jtag_bridge >>>> can properly sigle-step through jump instructions and OpenOCD can properly >>>> handle software breakpoints. >>>> >>>> -- >>>> mgr inż. Marek Czerski >>>> +48 696 842 686 >>>> >>> >>> One of the problem is showed on waveforms I posted. The instruction >>> trapped doesn't get executed after the breakpoint is removed. >>> >>> I have a fix almost ready. I checked for a debug unstall condition >>> plus a trap condition in or1200_du (dbg_stall && |except_stop). Then, >>> when this event occur, I flush the entire pipeline (in or1200_ctrl) >>> and set the pc to npc in or1200_genpc (which is equal to the trapped >>> instruction address). >>> >>> Franck. >> >> I have a fix ready. I works on VPI simulation. I don't know if it's a >> good or the right way to fix this but at least it seems to work.... >> If someone could give it a try on an hardware platform that would be >> great (because I'm not home this week end). >> >> Franck. >> >> I think we should apply this patch as it is only concerning the debug >> part of or1200 and it solves the problem. >> >> Marek and I have been using it for some times and didn't find any side >> effect. >> >> (should I fill a bug in bugzilla or it is too late now ?) >> >> Franck. >> >> _______________________________________________ >> OpenRISC mailing list >> [email protected] >> http://lists.openrisc.net/listinfo/openrisc >>
Done. http://bugzilla.opencores.org/show_bug.cgi?id=104 _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
