NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
wingsorc has quit [Ping timeout: 248 seconds]
kann has joined #openocd
PsySc0rpi0n has quit [Ping timeout: 252 seconds]
Hawk777 has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Steffanx has quit [Read error: Connection reset by peer]
drath42 has quit [Read error: Connection reset by peer]
Steffanx has joined #openocd
drath42 has joined #openocd
jacob_ has quit [Ping timeout: 252 seconds]
jacob_ has joined #openocd
Hawk777 has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
<karlp> wow, 0.10 is pretty old now, didn't know that was still knocking around anywhere
dreamcat4 has joined #openocd
slobodan has joined #openocd
Yamakaja has joined #openocd
<Yamakaja> Hey, does anyone around here happen to have an OpenOCD config for an atxmega256a3, or knows how to create one (or if it is possible to create one / What I need to do to create one myself)?
<Yamakaja> I'm using an Atmel ICE in JTAG mode (https://www.microchip.com/en-us/development-tool/ATATMEL-ICE)
<Haohmaru> Yamakaja, to do.. what with it?
<Haohmaru> afaik openocd can't debug these
<Haohmaru> also, can they even be debugged via JTAG?
<Haohmaru> shouldn't you be using the PDI
<PaulFertser> Yamakaja: do you take into account only flashing is possible, not debug?
<Yamakaja> Haohmaru It's quite possible that OpenOCD can't deal with them, that's why I'm asking here ;)
<Yamakaja> Oh, I was specifically looking for the ability to debug, not flash :/
<PaulFertser> Yamakaja: flashing for AVR parts over JTAG should work.
<PaulFertser> Yamakaja: for debugging you need something like "avarice".
<Haohmaru> i couldn't figure out avarice
<Haohmaru> so i gave up
<PaulFertser> Yamakaja: for ability to debug without extra problems you're welcome to try a Cortex-M based MCU instead.
<PaulFertser> Yamakaja: should be both cheaper and faster.
<Haohmaru> otherwise the atmel-ice worked via the nasty atmelstudio IDE with atxmega128a3u
<Yamakaja> PaulFertser sure, but unfortunately I will have to work with what I have
<PaulFertser> No idea if avarice even supports xmega parts.
<Yamakaja> According to the manual it does, I'll try and see if i can get it working!
<Haohmaru> that's btw the same xmega but with more flash
<Haohmaru> maybe without the USB
slobodan has quit [Ping timeout: 240 seconds]
slobodan has joined #openocd
<Yamakaja> So it was a bit finicky, but i believe avarice is working as expected :D
<PaulFertser> Yamakaja: cool to hear!
Deneb has joined #openocd
<blathijs> Related question: Can OpenOCD flash AVR parts over ISP (instead of JTAG) too? I believe not, but if it was possible I could use openocd for all my production boards instead of needing both avrude and openocd, would be convenient :-)
<PaulFertser> blathijs: JTAG is an ISP access method :)
<PaulFertser> If you mean AVR's SPI flashing protocol, no, sorry, avrdude should be able to do that with a JTAG adapter too I guess?
<PaulFertser> At least some ftdi adapters are supported by avrdude.
gzlb has quit [Ping timeout: 252 seconds]
<blathijs> PaulFertser: It's for an atmega16u2 that (I think) does not support JTAG (and even if it does, I only have the ISP pins broken out), so I think that means no.
<blathijs> And yeah, avrdude can do JTAG, but I'm using both AVR and STM32 boards :-)
gzlb has joined #openocd
slobodan has quit [Ping timeout: 248 seconds]
slobodan has joined #openocd
Boban has joined #openocd
<Boban> I'm looking to implement CTI support for peripheral halt on Cortex-M33. I'd like to know if OpenOCD supports this.
<Boban> The documentation doesn't explicitly mention CTI support for ARMv8-M but just ARMv8. Does this include ARMv8-M as well or only ARMv8-A parts?
<PaulFertser> Boban: hey
<PaulFertser> Boban: "git grep arm_cti_enable" makes it pretty clear it's aarch64 only.
wingsorc has joined #openocd
<Boban> Thanks
Boban has quit [Quit: Client closed]
crabbedhaloablut has quit []
Haohmaru has quit [Ping timeout: 250 seconds]
crabbedhaloablut has joined #openocd
<PaulFertser> Hm, a single build as done by "openocd-gerrit" takes less than 3 minutes. 5 of about the same plus distcheck on "openocd-gerrit-build" take an hour. Something's wrong there...
Hawk777 has joined #openocd
wingsorc has quit [Quit: Leaving]
peeps[work] has joined #openocd
Deneb has quit [Quit: Leaving]
wingsorc has joined #openocd
slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #openocd
fenugrec has joined #openocd
<fenugrec> Hi, I have issues with 'jtag drscan' :
<fenugrec> 1- error message is not helpful, "> jtag drscan ... wrong # args: should be "jtag drscan wrong arguments"
<fenugrec> 2- I have an auto-detected TAP : 'auto0.tap' . Still drscan is not happy : jtag drscan auto0.tap -> "wrong # args: ..."
<fenugrec> and 3- : segfault with "jtag drscan auto0.tap 32 1"
<Hawk777> I think the documentation states <https://openocd.org/doc-release/html/JTAG-Commands.html#index-drscan> you need at least one numbits/value pair (see the + beside the group). Anyway, obviously it should not segfault when the command is correct.
<Hawk777> So the error when you just send “jtag drscan auto0.tap” seems right, there *are* the wrong number of arguments: you passed one, and it needs at least three.
<fenugrec> Hawk777, yep, had to read the sourcecode to understand better. Just filed a ticket on SF for the segfault
<fenugrec> But the built-in help says "jtag drscan tap_name [num_bits value]* ['-endstate' state_name]", the bracket notation usually means optional elements but I just noticed the * which should probably be taken to mean 'at least one pair'
<PaulFertser> fenugrec: thank you for the tickets. Odd, drscan used to work for me, must be some regression or probably misunderstanding, I think I used it with taps defined, not autodetetcted.
<PaulFertser> What are ou trying to do btw?
<fenugrec> Hi PaulFertser, I'm off the beaten path here - poking an unknown XMOS part (probably xu216-*) , I have no BSDL and haven't really looked inside vendor binaries yet
<PaulFertser> fenugrec: are you aware about my script for working without bsdl?
<PaulFertser> For boundary scan
<Hawk777> Oh huh, interesting, * I would read as “zero or more” (as in regex), while + would be “one or more”. The web documentation has +, if the internal help has *, maybe that should be changed to match?
<fenugrec> (I'm just at the scan_chain step yet -) any idea why I'm getting "IR capture error at bit 2, saw 0x3ffffffffffffff5 not 0x...3" ? IDCODE returns a sane value
<fenugrec> Hawk777, I was thinking the same, but didn't know if the docs wanted to go full-regex style : )
<fenugrec> PaulFertser, not familiar with that script you mention ?
<PaulFertser> fenugrec: https://openocd.org/beyond_simple_debugging.html in this talk you can see an example of talking to "unknown" chip.
<fenugrec> oh good, will watch
<PaulFertser> It mentions where to grab the latest version of the scripts. Sorry I haven't upstreamed it :(
<Hawk777> If nothing else it seems to me that the web and internal documentation should say the same thing.
<PaulFertser> fenugrec: jtag scan verifies that it reads some well-known pattern from IR, and you can set the value and mask to expect.
<PaulFertser> 0x5 wouldn't match 0x3 with mask 0x3
<fenugrec> so... not really an error, just 'haven't told oocd enough about the TAP" ?
<PaulFertser> If the part is JTAG compliant it would have 0x3 there.
<fenugrec> hmm
<PaulFertser> But probably it's indeed not so you can tell OpenOCD what to expect.
<fenugrec> The JTAG chain [...] comprises a single 1149.1 compliant TAP that can be used for boundary scan of the I/O pins. It has a 4-bit IR and 32-bit DR. It also provides access to a chip TAP that in turn can access the xCORE Tile for loading code and debugging.
<fenugrec> quote from most likely IC match
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
<fenugrec> heh, I don't do much JTAG, and never this low-level
<fenugrec> I could also spend 50$ and get the vendor debugger. Not as expensive as I thought
<fenugrec> they already have a fork of openocd for an older generation of the same CPU, but probably similar
<fenugrec> how did I not find that earlier
<fenugrec> "jtag newtap xmos tap -irlen 4 -enable" gets rid of the IR capture error
slobodan has quit [Ping timeout: 250 seconds]
peeps[work] has quit [Ping timeout: 260 seconds]