NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
ttmrichter_ has quit [Quit: Bye]
ttmrichter has joined #openocd
nvmd has joined #openocd
ttmrichter has quit [Ping timeout: 260 seconds]
ttmrichter has joined #openocd
tsal has quit [Ping timeout: 264 seconds]
tsal has joined #openocd
nerozero has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
wingsorc has quit [Ping timeout: 260 seconds]
stefanct has joined #openocd
<stefanct> hello! i can't get openocd work with the beaglebone black soc. details and logs: https://dpaste.org/MYWBz/raw
<PaulFertser> stefanct: hi
<PaulFertser> stefanct: hm, is there a chance TDO line isn't actually connected?
<PaulFertser> stefanct: there shouldn't be any difference between using jlink and ftdi based adapters there, so you should be able to find success reports with this board and use for comparison.
<PaulFertser> stefanct: have you connected both TRST and SRST lines?
<stefanct> PaulFertser: there a chances for pretty much any error in the hardware setup tbh. i need a new soldering station :) both resets *should* be connected individually, yes. i'll try to measure all connections from pcb to the other end of the cable.
<stefanct> and the various guides about the bbb are contradicting themselves about the EMU lines a bit, so i wanted to ask first... brb
<PaulFertser> stefanct: I recommend Pinecil V2 instead of a soldering station.
<PaulFertser> stefanct: OpenOCD doesn't manipulate the EMU lines.
<Haohmaru> this pinecil looks interesting
<PaulFertser> And it runs RTOS which you can debug with OpenOCD ;)
<Haohmaru> nonono
<Haohmaru> the last thing i wanna have to debug is a soldering iron, or a toaster
<Haohmaru> it's kinda pricey tho
<PaulFertser> It feels like it's on par with many proper Weller soldering stations, and also can be used on the go with a power bank.
<Haohmaru> ~60 euros, which doesn't include a PSU
<PaulFertser> 26$ from official store. And you use any Type-C PSU you have handy.
<PaulFertser> And it beats many real soldering stations.
<Haohmaru> eh? i saw 61 euros on the eu store
<Haohmaru> you assume i have anything with USB type C?
<PaulFertser> EU store includes warranty and shipment and taxes.
<Haohmaru> i'm in .eu (still)
<PaulFertser> It also supports EPR chargers, and can go up to 28 V, with short tips that's plenty of power.
<PaulFertser> You can buy from global store too.
<karlp> I got an aixun t3b recently, as an upgrade to an old (old!) hakkko 936, and it's _amazing_ I love it.
<Haohmaru> i use a ~5euro iron which plugs directly in the mains ;P~
<PaulFertser> Haohmaru: using a temperature controlled iron is much more comfortable and safer.
<Haohmaru> it's 30W
<PaulFertser> 200 W eh
cousteau has joined #openocd
<Haohmaru> i use the same kind of iron @job, have soldered a ton of boards so far
<Haohmaru> only a few times i've managed to take a copper pad off the board by accident
<Haohmaru> twice maybe
<Haohmaru> the last time i was trying to make a solder blob on a solder-jumper and it didn't want to bridge.. took forever and finally one of the pads got off the board
<PaulFertser> That aixun kinda looks like JBC.
<karlp> yeah, they take jbc tips as well
<karlp> they have a t3a that takes the bigger jbc tips too.
<karlp> they have a version of it that takes tsger style tips and hakko tips, but the jbc style tips are _fantastic_
<Haohmaru> oh, wait, i think i'll need also a stand for this pinecil, it's very thin
<PaulFertser> Yeah
<Haohmaru> meh, i'll think about it
<Haohmaru> but i definatelly don't have space for a whole station on my desk
<Haohmaru> having the controls onto the iron handle seems more convenient
<karlp> I got that "station" because it's super small, but yeah, it's defiitely space somewhere.
<stefanct> PaulFertser: IMHO the connections are all working as *I* intended. but maybe they are wrong... this should reflect what's there https://ibb.co/Hzpvfj0
<PaulFertser> stefanct: I can't see how wrong connections can lead to output you have, the tdo theory was my best guess...
<stefanct> PaulFertser: two things that might be worth noting: i have connected TCK and RTCK because they are(?) connected on the beaglebone pcb according to the schematic anyway. and i have not connected all gnd lines because soldering was so frustrating
<PaulFertser> stefanct: does jlink have integrated series resistors on data lines?
<PaulFertser> stefanct: hm, you can try just adding another gnd connection in parallel, sometimes it's essential.
<stefanct> i have feared that reply :)
<PaulFertser> Do you have an oscilloscope?
<stefanct> just a logic analyzer
<cousteau> https://openocd.org/doc/html/Server-Configuration.html#tcpipports says that tcl_port defaults to 6666 but https://openocd.org/doc/html/General-Commands.html says 5555. What is it, then?
<cousteau> I think my version (an old one) uses 6666
<Haohmaru> o_O
<Haohmaru> 6666 is almost the IRC port
<cousteau> It's like a devil and a third
<Haohmaru> i thought openocd is on port 3333 by default
<cousteau> But yeah, there doesn't seem to be a strong consensus on what ports are reserved for what
<cousteau> Haohmaru: for GDB it is, but for Telnet it's 4444 and for Tcl it's 5555/6666
<Haohmaru> it's adjustable so who cares
<Haohmaru> oh, you mean TCL?
<Haohmaru> no idea about that stuff.. i've only used IDE+gdb+openocd so far
<cousteau> ...it's spelled Tcl, dammit! :)
<Haohmaru> meh
<cousteau> Sorry, I thought you were correcting me so I was playing along
<stefanct> i think the general commands page is wrong but i dont really know
<cousteau> But anyway, my point is that the documentation seems wrong and needs to be fixed (or I'm missing something)
<stefanct> fwiw, my 12 hours old openocd defaults to 6666 according to its log
<cousteau> Sweet, so my OpenOCD is new-ish, after all!
<Haohmaru> which version is it?
<cousteau> No idea. Too old. Lemme check
<cousteau> It says 0.10.0
<Xogium> jesus that is old
<Haohmaru> not super old
<Xogium> no no I saw worse
<Xogium> but still more than a year ago for sure
<cousteau> I think it's a custom build that was provided with some toolchain
<Haohmaru> oh noes
<Haohmaru> a counterfeit openocd
<cousteau> ...one year ago is "Jesus that is old"? Come on
<karlp> tcl port and telnet port and gdb port are all different.
<cousteau> "custom build" as in "they probably enabled some build option that isn't enabled by default"
<cousteau> karlp: yeah but it says here tcl port is 6666 but says 5555 there
<karlp> yeah, general commands is wrong.
<karlp> weirdly though a couple of target scripts explicitly set to 5555 :|
<cousteau> The thing is, I'm pretty sure I've seen 5555 somewhere before... maybe in an older version?
<cousteau> karlp: yeah, maybe for backwards compatibility with older versions that used 5555
<cousteau> The older versions hypothesis gains momentum
<cousteau> TCP 6665-6669 seem to be officially registered for IRC
<cousteau> Whereas 5555 is only unofficially used for some stuff, but not officially registered
<cousteau> https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers (interestingly, OpenOCD's 3333 & 4444 are listed there, but no mention of 5555 nor 6666 for OpenOCD)
<cousteau> In short, better not to run OpenOCD on computers running IRC servers... or at least do so carefully
<cousteau> (didn't know computers existed in 2008)
<cousteau> With the very descriptive explanation/justification for the change "moving Tcl stuff around slightly" (maybe the SVN repo contained more details)
<cousteau> So yeah I doubt I actually ever saw a version of OpenOCD using port 5555
<cousteau> (which made more sense because it wasn't registered for IRC and it was sequential with 3333-4444-5555, but... *shrugs*)
<cousteau> Oh and this is nice, I can set them to 0 to disable them if I don't need them
cousteau has quit [Ping timeout: 265 seconds]
<stefanct> two more gnds, no change
<Haohmaru> PaulFertser is the tip on the pinecil wired to gnd internally?
<PaulFertser> Haohmaru: I suggest you ask on their channel, can't tell for sure.
<Haohmaru> #pinecil ?
<PaulFertser> stefanct: oh. I wouldn't have suggested it if I haven't seen it helping myself, but of course it's not a silver bullet, and the problem might be somewhere else entirely.
<PaulFertser> Haohmaru: pine64 community has their own IRC server bridged to some other platforms.
<Haohmaru> meh
<Haohmaru> okay..
<stefanct> PaulFertser: i don't blame you at all, i was thinking about it myself :)
<PaulFertser> stefanct: what happens if you try "reset halt" command? I suggest you use -d3 log, not -d4, as it's not about debugging jlink support code.
<karlp> gerrit has beeen suuuuuper slow recently :|
cousteau has joined #openocd
<karlp> oh, cousteau left.
<cousteau> Yep :(
<Haohmaru> and now he right
<cousteau> I'm using irc over Android and the thing is not precisely the most stable thing
<cousteau> karlp: sorry, you were saying?
<PaulFertser> stefanct: I would also probably try 0.10.0 with the same hardware, just in case it's some regression.
<karlp> oh, I was just going to link you https://review.openocd.org/c/openocd/+/7385 :)
<stefanct> PaulFertser: stupid question: how can i use a command, if openocd exits due to the errors? or do you mean instead/before the two supplied files?
<stefanct> PaulFertser: 0.10.0 does not have the configuration files for the bbb (and a different syntax so i can't just supply the new ones). i started with 0.11.0~rc2-1 before trying git in case something got fixed :D
<cousteau> karlp: thanks! :) Much appreciated
<PaulFertser> stefanct: you do not need bbb config, it's enough to use the SoC config, and it should be there in 0.10.0.
<karlp> cousteau: I think 5555 also conflicts with some fpga debug ports that are used by some openocd targets as well,
<cousteau> Maybe precisely because openocd used them?
<karlp> probably.
<cousteau> Because that'd be sort of a self-caused issue
<cousteau> Like, maybe that causes the same issue to exist in the future with port 6666
<stefanct> AFAICS there is no difference with 0.10.0, with this in an -f'ed file:
<stefanct> source [find interface/jlink.cfg]
<stefanct> adapter_khz 1000
<stefanct> source [find target/am335x.cfg]
<stefanct> reset_config trst_and_srst
<stefanct> it repeats the Error: Invalid ACK (7) in DAP response lines two dozen times or so
<stefanct> i'll try with an ftdi breakout board that i've been using for jtag debugging a riscv soft-core before... i dont trust that segger thing anymore
<PaulFertser> stefanct: makes sense to try, yes. Just keep in mind a regular breakout board lacks series termination resistors so it can produce ringing with some targets.
<stefanct> yeah, but it's easy enough to try. no idea about the termination in that jlink thing btw
zjason`` has joined #openocd
zjason` has quit [Ping timeout: 260 seconds]
cousteau has quit [Ping timeout: 260 seconds]
Haohmaru has quit []
ttmrichter has quit [Quit: Bye]
nerozero has quit [Ping timeout: 264 seconds]
sys64738 has quit [Ping timeout: 252 seconds]
sys64738 has joined #openocd
<zmatt> stefanct: the fact it can read out the jtag idcode suggests the physical connection is working fine. the invalid 111 response seems to imply TDO is getting held high after the DAP tap got linked into the chain, which afaik implies the tap is not properly powered/clocked
<zmatt> which is odd if you're doing this before linux is loaded (which, as you mentioned, may disable the clock depending on DT)
<PaulFertser> I think I remember seeing idcode readout without some line connected too, as IDCODE command is pre-loaded in the IR after reset.
<zmatt> idcode is not pre-loaded after reset here
<zmatt> afaik
<zmatt> nor can it be selected using a stuck TDI since the IR value required is 0b000100
ttmrichter has joined #openocd
<zmatt> I don't remember if I've ever used openocd with a beaglebone or only TI's debug server
<zmatt> I guess I could give it a try, once I'm a bit more awake and less lazy
<PaulFertser> I can't find the proper reference to this statement "after resetting tap, if one moves directly into shift-dr state, idcode instruction gets loaded and one can shift-out 32-bit device id."
<zmatt> hmm you may actually be right here, I probably just misremembered
<zmatt> it's been a while since I've had my head deep in jtag
<PaulFertser> Same here
<zmatt> you're right, it should be in idcode after reset
<zmatt> still, if TDI or TDO were stuck I'd expect an error while doing the ICEPick dance to link in the DAP tap
<PaulFertser> But I was wrong about TDO not connected idea, if anything, it's TDI.
<zmatt> while I'm assuming "Info : JTAG tap: am335x.tap enabled" means the interaction with ICEPick was a success
<PaulFertser> Indeed, icepick is like that, so everything must be connected.
<PaulFertser> I found some similar reports on the Internet, neither had any resolution unfortunately.
<zmatt> and "Error: Invalid ACK (7) in DAP response" suggests TDO is stuck high after linking in the tap
<PaulFertser> Agreed
<zmatt> which suggests this happened: "When a selected secondary TAP becomes inaccessible due to power constraints, all secondary TAPs are deselected. TDO is forced to Hi-Z."
<zmatt> oh
<stefanct> tdi and tdo are definitely not stuck (and not floating either), that much i can tell you
<zmatt> target/am335x.cfg links in the tap of the wakeup cortex-m3 controller
<zmatt> but it isn't accessible until its reset gets released by linux
<zmatt> hmm or does it define it but not enable it
<zmatt> never mind it looks like it only enables the main DAP tap by default
<PaulFertser> stefanct: try booting Linux just in case
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
<stefanct> i am struggling a bit with the trst and srst settings for the ftdi adapter
<stefanct> the gpios used in ftdi layout_signal have to be set up correctly in layout_init AFAICT
<stefanct> the LEDs do work, but the resets seem to do nothing apart from the init part
<stefanct> ftdi layout_init 0x7808 0x780b
<stefanct> ftdi layout_signal nTRST -data 0x2000 -oe 0x2000
<stefanct> ftdi layout_signal nSRST -data 0x4000 -oe 0x4000
<stefanct> ftdi layout_signal LED -ndata 0x1800
<stefanct> ac5 and ac6 are supposed to be trest and srst, respectively
<PaulFertser> You also need reset_config "trst_and_srst" and then OpenOCD will use them when resetting.
<zmatt> board/ti_beaglebone_black.cfg contains reset_config trst_and_srst
<stefanct> ah damn, right, of course :)
<stefanct> i am still a bit confused. apparently the rest lines should NOT be set in layout_init
<stefanct> if i dont do that, i actually see a reset on trst at the beginning
<stefanct> for some reason, i dont see one on srst though
<stefanct> on less bad news... seems like the connection works better
<stefanct> but havent debugged yet
danselmi has joined #openocd
<PaulFertser> stefanct: hm, so clone jlink really did something bad? Weird story.
sbach has quit [Ping timeout: 264 seconds]
sbach has joined #openocd
wingsorc has joined #openocd
erhankur has joined #openocd
erhankur has quit [Client Quit]
danselmi has quit [Quit: Client closed]