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)?
<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>
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>
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