Hello Joe, I have checked the OpenOCD code and this indeed appears to be an OpenOCD bug, exactly as you describe. It affects not only this upstream OpenOCD but the riscv-openocd fork where the RISC-V related development takes place. I have submitted a fix at: https://github.com/riscv/riscv-openocd/pull/547 Could you please check if the fixed code works all right for you?
Thank you and regards, Jan On Wed, Oct 14, 2020 at 2:34 AM Tommy Murphy <tommy_mur...@hotmail.com> wrote: > Might it be better to log this as an issue against the sifive fork of > openocd (for RISC-V support) which has not yet been fully upstreamed to the > main openocd project/repo? > ------------------------------ > *From:* Joe Stoy <s...@bluespec.com> > *Sent:* Tuesday, October 13, 2020 11:21:42 PM > *To:* openocd-devel@lists.sourceforge.net < > openocd-devel@lists.sourceforge.net> > *Subject:* [OpenOCD-devel] Bug report: RISC-V sba, incomplete recovery > after sbbusyerror > > This refers to "Open On-Chip Debugger 0.10.0+dev-g27c0fd7a > (2020-01-04-05:57)". > > When controlling a RISC-V debug module, using system bus access with > autoincrementing bursts, if sbbusyerror is set, openocd currently clears > the error bit by writing 0x00400000 to the sbcs register. This also clears > all the R/W bits in the word (specifically the autoincrement bit and the > access size), but openocd proceeds as though they remained as they were. > > The first section of the attached file shows a fragment from the (very > long) openocd.log. Line 7844 shows the initial setting of sbcs, and an > initial burst follows. Lines 7873/4 show the sbbusyerror bit set, and line > 7877 shows the write to clear it. But then the next burst is started > without respecifying autoincrement etc. > > openocd should set these bits again, either in the write which clears the > error (perhaps simply by writing back the value just read), or > alternatively by setting the required fields before each burst. The second > section of the attached file gives a patch (untested) provided by a > colleague, taking the second approach. > > joe > > > >
_______________________________________________ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
