Thanks, Tommy. I'd thought of doing it all in TCL before `init` but I feel it gets rather unwieldy, and I'd end up rewriting a bunch of the RISC-V target code in TCL just to make it happen.
Tim On Mon, Jan 6, 2020 at 2:18 PM Tommy Murphy <[email protected]> wrote: > Hi Tim > > FWIW we (Microchip/Microsemi) have a similar situation with our > SmartFusion/SmartFusion2 SoC FPGAs which have an FPGA top level TAP and > also a hard Cortex-M3 with its own TAP in the MSS (Microcontroller > Sub-system). The former has to be negotiated and a special command sent > before the latter can be accessed. The attached target script shows how we > manage this. Perhaps (some of) this might be relevant to your situation? > > Hope this helps > Regards > Tommy > > ------------------------------ > *From:* Tim Newsome <[email protected]> > *Sent:* Monday 6 January 2020 20:05 > *To:* OpenOCD ML <[email protected]> > *Subject:* [OpenOCD-devel] handle targets that are inaccessible when > connecting > > I have a RISC-V target with 2 TAP controllers chained together. The first > controller connects to a core that's always accessible. The second > controller connects to a core that's only accessible after the first core > has done some setup, which (at least initially) requires the debugger. > > If I just configure both of those and connect then OpenOCD errors out > because examine() fails on the core behind the second controller because > it's not powered up yet. How can I change the code to make this case work? > Is there an example for some other target? > > Tim >
_______________________________________________ OpenOCD-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openocd-devel
