09:24 <karlp> wow, 0.10 is pretty old now, didn't know that was still knocking around anywhere

12:00 <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)?

12:01 <Yamakaja> I'm using an Atmel ICE in JTAG mode (https://www.microchip.com/en-us/development-tool/ATATMEL-ICE)

12:02 <Haohmaru> Yamakaja, to do.. what with it?

12:02 <Haohmaru> afaik openocd can't debug these

12:03 <Haohmaru> also, can they even be debugged via JTAG?

12:03 <Haohmaru> shouldn't you be using the PDI

12:03 <PaulFertser> Yamakaja: do you take into account only flashing is possible, not debug?

12:04 <Yamakaja> Haohmaru It's quite possible that OpenOCD can't deal with them, that's why I'm asking here ;)

12:04 <Yamakaja> Oh, I was specifically looking for the ability to debug, not flash :/

12:04 <PaulFertser> Yamakaja: flashing for AVR parts over JTAG should work.

12:04 <PaulFertser> Yamakaja: for debugging you need something like "avarice".

12:05 <Haohmaru> i couldn't figure out avarice

12:05 <Haohmaru> so i gave up

12:05 <PaulFertser> Yamakaja: for ability to debug without extra problems you're welcome to try a Cortex-M based MCU instead.

12:05 <PaulFertser> Yamakaja: should be both cheaper and faster.

12:05 <Haohmaru> otherwise the atmel-ice worked via the nasty atmelstudio IDE with atxmega128a3u

12:05 <Yamakaja> PaulFertser sure, but unfortunately I will have to work with what I have

12:06 <PaulFertser> No idea if avarice even supports xmega parts.

12:07 <Yamakaja> According to the manual it does, I'll try and see if i can get it working!

12:11 <Haohmaru> that's btw the same xmega but with more flash

12:11 <Haohmaru> maybe without the USB

12:22 <Yamakaja> So it was a bit finicky, but i believe avarice is working as expected :D

12:31 <PaulFertser> Yamakaja: cool to hear!

13:39 <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 :-)

13:44 <PaulFertser> blathijs: JTAG is an ISP access method :)

13:45 <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?

13:46 <PaulFertser> At least some ftdi adapters are supported by avrdude.

14:03 <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.

14:03 <blathijs> And yeah, avrdude can do JTAG, but I'm using both AVR and STM32 boards :-)

14:19 <Boban> I'm looking to implement CTI support for peripheral halt on Cortex-M33. I'd like to know if OpenOCD supports this.

14:19 <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?

14:34 <PaulFertser> Boban: hey

14:36 <PaulFertser> Boban: "git grep arm_cti_enable" makes it pretty clear it's aarch64 only.

15:04 <Boban> Thanks

17:57 <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...

20:58 <fenugrec> Hi, I have issues with 'jtag drscan' :

20:59 <fenugrec> 1- error message is not helpful, "> jtag drscan ... wrong # args: should be "jtag drscan wrong arguments"

21:00 <fenugrec> 2- I have an auto-detected TAP : 'auto0.tap' . Still drscan is not happy : jtag drscan auto0.tap -> "wrong # args: ..."

21:01 <fenugrec> and 3- : segfault with "jtag drscan auto0.tap 32 1"

21:03 <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.

21:03 <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.

21:07 <fenugrec> Hawk777, yep, had to read the sourcecode to understand better. Just filed a ticket on SF for the segfault

21:08 <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'

21:09 <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.

21:10 <PaulFertser> What are ou trying to do btw?

21:11 <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

21:11 <PaulFertser> fenugrec: are you aware about my script for working without bsdl?

21:12 <PaulFertser> For boundary scan

21:12 <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?

21:12 <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

21:13 <fenugrec> Hawk777, I was thinking the same, but didn't know if the docs wanted to go full-regex style : )

21:13 <fenugrec> PaulFertser, not familiar with that script you mention ?

21:13 <PaulFertser> fenugrec: https://openocd.org/beyond_simple_debugging.html in this talk you can see an example of talking to "unknown" chip.

21:14 <fenugrec> oh good, will watch

21:14 <PaulFertser> It mentions where to grab the latest version of the scripts. Sorry I haven't upstreamed it :(

21:14 <Hawk777> If nothing else it seems to me that the web and internal documentation should say the same thing.

21:16 <PaulFertser> fenugrec: jtag scan verifies that it reads some well-known pattern from IR, and you can set the value and mask to expect.

21:17 <PaulFertser> 0x5 wouldn't match 0x3 with mask 0x3

21:17 <fenugrec> so... not really an error, just 'haven't told oocd enough about the TAP" ?

21:18 <PaulFertser> If the part is JTAG compliant it would have 0x3 there.

21:18 <fenugrec> hmm

21:18 <PaulFertser> But probably it's indeed not so you can tell OpenOCD what to expect.

21:19 <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.

21:19 <fenugrec> quote from most likely IC match

21:22 <fenugrec> heh, I don't do much JTAG, and never this low-level

21:28 <fenugrec> I could also spend 50$ and get the vendor debugger. Not as expensive as I thought

21:31 <fenugrec> OH good grief - https://www.xmos.ai/file/desktop-tools-openocd/

21:31 <fenugrec> they already have a fork of openocd for an older generation of the same CPU, but probably similar

21:32 <fenugrec> how did I not find that earlier

21:39 <fenugrec> "jtag newtap xmos tap -irlen 4 -enable" gets rid of the IR capture error