boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
The_Jag has joined #openocd
The_Jag_ has quit [Ping timeout: 260 seconds]
tsal has quit [Ping timeout: 264 seconds]
tsal has joined #openocd
mithro has quit [Read error: Connection reset by peer]
devanagram has quit [Ping timeout: 245 seconds]
dreamcat4 has quit [Ping timeout: 260 seconds]
dreamcat4 has joined #openocd
mithro has joined #openocd
mithro has quit [Ping timeout: 258 seconds]
dreamcat4 has quit [Ping timeout: 258 seconds]
dreamcat4 has joined #openocd
devanagram has joined #openocd
mithro has joined #openocd
nerozero has joined #openocd
Hawk777 has quit [Quit: Leaving.]
Bertl_oO is now known as Bertl_zZ
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Coldblackice has joined #openocd
bq has joined #openocd
<bq>
Should I be concerned if I get a "IR capture error at bit 2, saw 0x05 not 0x...3" error after a successful tap scan?
<bq>
The target is a bit of an odd one for me - it has TDO, TDI, TMS and TCK. No resets
<bq>
But I'm presuming this is normal for FPGA
<bq>
Hmm. Seems to go away with irlen set to 8. Where should this value come from?
<PaulFertser>
bq: hi
<PaulFertser>
bq: your FPGA manual should tell you the IR length, and you should use exactly that in the config.
<PaulFertser>
bq: if you still get capture error with that then probably the target is not compliant and you can use different irmask or ircapture value to ignore that.
<PaulFertser>
bq: you can generate an SVF file for your FPGA with vendors tools and you'll see real IR length there inside (SVF is plain text).
thinkfat has joined #openocd
thinkfat has quit [Read error: Connection reset by peer]
thinkfat has joined #openocd
thinkfat_ has joined #openocd
thinkfat has quit [Ping timeout: 260 seconds]
Thane has joined #openocd
Thane has left #openocd [...]
Bertl_zZ is now known as Bertl
Hawk777 has joined #openocd
Bertl is now known as Bertl_oO
nerozero has quit [Ping timeout: 264 seconds]
<diddly>
Hello, it seems that the latest release of ChibiOS changed some data structures rendering the openocd -rtos chibios feature broken. Is there a proper place to file a bug, and/or reach out to the original author?
<PaulFertser>
diddly: yes, you can report a bug or (even better) offer a fix to the code.
<PaulFertser>
diddly: the original ChibiOS code was written many years ago, and not changed since then (other than tree-wide cleanups).
<diddly>
Hmm, yea and it seems that was the authors only contribution so not going to be fresh in their mind either
<PaulFertser>
diddly: another thing to try is to use "message:chibios" search on https://review.openocd.org , probably someone has already sent a patch.
<diddly>
I'll see if I can get some info from the ChibiOS author as to what needs to happen and see if I can figure out a way ahead
<diddly>
PaulFertser: hmm nothing on Gerrit unfortunately
<PaulFertser>
diddly: well, you can just sit down and fix it. If you have some specific questions about OpenOCD rtos code I might be able to answer. First thing to do would be to run openocd with -rtos chibios with -d2 or -d3 and note what exactly fails about the chibios code.
<diddly>
as I understand, when he added SMP support the stackup changed and needs some massaging. To do it right though, ideally it should detect which ChibiOS and support both formats
<diddly>
I'll have a deeper look in the next couple weeks and see if I can ask more intelligent questions :)
<PaulFertser>
diddly: sounds sane :)
zjason` has joined #openocd
zjason has quit [Ping timeout: 258 seconds]
Hawk777 has quit [Quit: Leaving.]
<bq>
PaulFertser, ah, cool tip about using a produced SVF to see the irlen