<Haohmaru>
i run openocd in a terminal outside the IDE
<jancoow>
I am not
<jancoow>
PaulFertser if I enable reset_config trst_and_srst I'm unable to connect anymore so
<jancoow>
I would expect seeing a reset external
<jancoow>
but it keeps triggering a reset software
<jancoow>
is using -interpreter-exec console \"monitor reset halt\" wrong?
<PaulFertser>
jancoow: there's "openocd: Error: 96 90 core.c:620 adapter_system_reset(): BUG: can't assert SRST" in your log!
<PaulFertser>
Wasn't it visible with default debug level?
<Haohmaru>
^ what causes this inability?
<Haohmaru>
debugger doesn't control the reset pin?
<PaulFertser>
Haohmaru: OpenOCD isn't supposed to touch that pin because it's not enabled in the reset config, yes.
<Haohmaru>
oh, you mean some config tells openocd that the reset pin shall not be touched, and then later some algorithm attempts to touch it but openocd rejects it due to config?
<PaulFertser>
And indeed since it's not enabled OpenOCD just does this: openocd: Debug: 235 333 cortex_m.c:1516 cortex_m_assert_reset(): [atsaml21e18b.cpu] Using Cortex-M SYSRESETREQ
<Haohmaru>
that smells like soft-reset
<PaulFertser>
It's interesting how this buggy way works to attach to saml part though. It's not meant to be working like that but it does here, I see from the log and source code.
<PaulFertser>
jancoow: ready for my theory?
<Haohmaru>
do tell if you think something could work also for the SAME54 "security bit" case
<PaulFertser>
Haohmaru: here it probably works because there's enough time between deasserting reset while SWD pins are still working before disabled by firmware.
<Haohmaru>
ah right, his case is different than mine
Guest33 has joined #openocd
<Guest33>
Hi All, just wondering is there any effort providing support for ch32v targets riscv based debug over swd type of transport layer?
<jancoow>
PaulFertser ye go ahead :D
<jancoow>
now i'm curious
<jancoow>
PaulFertser so it's unable to use the hardware reset pin?
JoseT has joined #openocd
<karlp>
Guest33: they'd have to support swd first...
<PaulFertser>
jancoow: well, apparently your target doesn't actually support "srst_nogate", in other words, it doesn't talk SWD or JTAG while SRST is asserted at all.
<karlp>
there's an openocd fork that has support for ch32v with some wchlink interfaces, but it's pretty flaky, and not at all close to being upstreamed
<PaulFertser>
jancoow: so you can use hardware reset but without srst_nogate (and naturally without connect_assert_srst).
<PaulFertser>
jancoow: why it's working for you there is likely because OpenOCD CMSIS-DAP driver specifically ignores that SRST is not available and still tries to use it for connecting under reset, but CMSIS-DAP firmware seems to handle it somehow on its own and deasserts reset before actual communication. And OpenOCD has enough time to talk to target after that before SWD is turned off in software.
<PaulFertser>
jancoow: hah, what you can do as a trick is using that bug as you do currently for connecting, then change "reset_config" in runtime after it by adding "srst_only srst_gates_jtag connect_deassert_srst" and that should make all resets use hardware reset.
<Haohmaru>
i think i saw some room in daplink firmware for "target-specific" reset procedures
<Haohmaru>
but no idea if this is related or what it is at all
<PaulFertser>
I don't know either.
<PaulFertser>
Probably no and it's just pulling SRST low on init and then deasserts normally after openocd: Error: 96 90 core.c:620 adapter_system_reset(): BUG: can't assert SRST and then justt proceeds to connecting in the time window just opened.
<PaulFertser>
jancoow: hm, re power-savings with SWD pins and reliability, isn't it normally enough to just add external pulls so that they're not floating?
<PaulFertser>
(if the target doesn't have internal ones for the purpose)
<Haohmaru>
most SAM chips recommend having an external pull resistor on SWCLK
<Haohmaru>
quite a low value even, like 1k
<PaulFertser>
So if you have one then it's not leaking any energy right?
<PaulFertser>
Only really floating pins are bad like that.
<PaulFertser>
Please consider using imgbb.com in the future.
<PaulFertser>
What's the "related link" there?
<Haohmaru>
no idea.. however, there's also another illustration for when you wanna use a button for external reset, there they show 10k pull up resistor
<Haohmaru>
plus a capacitor tho
<Haohmaru>
oh wait, this is the reset pin, not SWCLK
Guest33 has quit [Quit: Client closed]
<Haohmaru>
i guess coffee levels are low
<Haohmaru>
could maybe the text that talks about "related link" be about the Xplained board?
<Haohmaru>
ah, found it, they've copy-pasted this from other datasheets but removed the actual link
<Haohmaru>
from SAMD20 datasheet, there's a link to "Operating in noisy environments"
<Haohmaru>
"If the device is operating in an environment with much electromagnetic noise it must be protected from this noise to ensure reliable operation. In addition to following best practice EMC design guidelines, the recommendations listed in the schematic checklist sections must be followed. In particular placing decoupling capacitors very close to the power pins, a RC-filter on the RESET pin, and a pull-up resistor on the SWCLK pin is critical for
<Haohmaru>
reliable operations. It is also relevant to eliminate or attenuate noise in order to avoid that it reaches supply pins, I/O pins and crystals."
<Haohmaru>
same thing in the SAMD21 datasheet
<Haohmaru>
1k pullup on SWCLK
<Haohmaru>
most of these say they have built-in pull up on the RESET pin, but still most of them recommend having also an external pull up resistor (different values in different chip datasheets are given) plus a capacitor
<PaulFertser>
Good to know!
<Haohmaru>
i just follow those recommendations and don't think about it much ;P~