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 <tom...@ho...>
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 <st...@bl...>
> *Sent:* Tuesday, October 13, 2020 11:21:42 PM
> *To:* ope...@li... <
> ope...@li...>
> *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
>
>
>
>
|
