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 > _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
