NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
akaWolf has quit [Ping timeout: 268 seconds]
akaWolf has joined #openocd
Hawk777 has quit [Quit: Leaving.]
emeb has quit [Quit: Leaving.]
c4017_ has joined #openocd
Hawk777 has joined #openocd
thinkfat_ has joined #openocd
thinkfat has quit [Ping timeout: 272 seconds]
boru` has joined #openocd
boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
tsal has quit [Ping timeout: 240 seconds]
tsal has joined #openocd
wingsorc has joined #openocd
nerozero has joined #openocd
akaWolf has quit [Ping timeout: 265 seconds]
wingsorc has quit [Quit: Leaving]
akaWolf has joined #openocd
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #openocd
Hawk777 has quit [Quit: Leaving.]
akaWolf has quit [Ping timeout: 272 seconds]
akaWolf has joined #openocd
joconor_ has joined #openocd
joconor has quit [Ping timeout: 258 seconds]
urja has quit [Read error: Connection reset by peer]
urja has joined #openocd
emeb has joined #openocd
Hawk777 has joined #openocd
<cyrozap> Matt144: Looking at those photos you posted, it looks a lot like the Intel flash is connected to the SHARC, and the SHARC is connected to the FPGA via its parallel memory interface. If the external serial port is connected to the FPGA, then I'm almost certain that the FPGA just contains a MAC for that serial interface, exposed as an MMIO device to the SHARC, and the SHARC is what loads the bitstream from
<cyrozap> flash into the FPGA.
<cyrozap> Your best bet is to dump that flash, get someone to write a SHARC disassembler (or do it yourself--it's not too difficult to write a Ghidra processor module), and then try and figure out where the SHARC handles the serial comms in its code.
<cyrozap> btw, I highly encourage you to post your reverse-engineering findings (PCB photos, connector pinout, serial protocol, hardware details, etc.) online somewhere, whether it's on a personal website, GitHub/GitLab/etc., hackaday.io, or anywhere else that'll get indexed by a search engine. That way, if someone else happens to have one of those same devices, or acquire one in the future, they won't have to
<cyrozap> start reverse engneering it from scratch like you did.
nerozero has quit [Ping timeout: 265 seconds]
_franck_3 has joined #openocd
_franck_ has quit [Ping timeout: 272 seconds]
_franck_3 is now known as _franck_
Guest83 has joined #openocd
<Guest83> Hello all. I'm trying to use openocd to start debugging a chip, and I'm struggling with "Error: Invalid ACK (6) in DAP response." If i use the d3 tag, it looks like this is coming from jtagdp_overrun_check(). What would cause this? My target is a qualcomm chip so I don't know much about it, and I've just started poking at it after finding the JTAG
<Guest83> pins with a jtagulator.
<PaulFertser> Guest83: you can share your -d3 log on some pastebin, probably someone here has an idea
<Guest83> Sure, put up paste with d3 output and the .cfg file I was using. https://pastebin.com/xkpKQjbA
<PaulFertser> Guest83: hm, if it's arm9 shouldn't you be creating an arm9<something> target rather than a dap?
<PaulFertser> I think this DAP is Cortex-specific.
<Guest83> PaulFertser - you're the best, I modified my .cfg file to create the tap and then create a target like: target create $_TARGETNAME arm926ejs -chain-position $_TARGETNAME and it appears to be working now (I can at least halt the target and get the pc). Thanks for the insight.
<PaulFertser> Guest83: good luck with your REing!