<Haohmaru>
i was trying to do that on an SAME54 which i "secured" and it doesn't work, i found some old patch and posts about "cold-plug" implemented in the other "target" for the smaller SAM chips (cortex-M0+ and such) and i tried to use that
<jancoow>
oh really?
<jancoow>
so officially they only implemented hot plug mode?
<Haohmaru>
i had to fool openocd that this is not a SAME54 and had to use an older version of openocd where this patch works
<Haohmaru>
iirc
<jancoow>
that's annoying for development as well..
<Haohmaru>
and iirc i tried to modify current openocd with this "cold-plug" thing but i failed to
<jancoow>
it's the most easy one
<Haohmaru>
i forgot the details, but basically newer openocd reads a few things on connect to the target, and when the chip is "protected" some of the registers read back as "errors" or something, but this is the expected behavior when "protected" and should be ignored, but openocd doesn't ignore it and stops at this point
<Haohmaru>
or something like that, i don't remember anymore
<PaulFertser>
jancoow: what exactly do you want for reset pin to do? "reset_config connect_assert_srst" probably?
<Haohmaru>
actually, it might actually work on the MCUs which are on that config, my issue was that i needed it for SAME54 which is treated as a different thing in openocd
<Haohmaru>
so listen to mr PaulFertser
<PaulFertser>
Haohmaru: doesn't that page 86 looks exactly like what you had?
<PaulFertser>
jancoow: not strange since pulling down SWCLK is not standard and not supported by all SWD adapters.
<Haohmaru>
i don't remember
<Haohmaru>
but the procedure is called "cold-plugging" in my case too
<Haohmaru>
and the "smaller" SAM chips have it too
<Haohmaru>
SAML21 is among those but i'm less familiar with it, i'd guess it's the same
<Haohmaru>
note that it uses a patched openocd-0.10.0
<Haohmaru>
and "at91samdXX.cfg" (this is for the small SAM chips)
<Haohmaru>
and notice that i'm invoking openocd twice because the first command causes openocd to think that it "failed" and won't execute the 2nd command with one invokation
<jancoow>
saml is same as samd
<Haohmaru>
hm, there was one which was quite different, which was it
<Haohmaru>
SAML11?
<jancoow>
saml21 is the low power variant of samd
<Haohmaru>
it was even some cortex-M23 or something like that
<Haohmaru>
"low power", more like, it has USB and cryptography and DMA
<Haohmaru>
SAMD20 has none of that
<Haohmaru>
SAMD21 does have USB and DMA
jybz has quit [Ping timeout: 246 seconds]
<jancoow>
we run all our products on saml/samr with an idle power usage of ~2ua
<jancoow>
however we got a few back which magically hangs in a 80ua state
<Haohmaru>
ah, there: SAML10 and SAML11 are cortex-M23 with TrustZone and what not
<jancoow>
and i probably tackled this down by some weird errate about hot plug..
<Haohmaru>
jancoow, in any case, follow what PaulFertser said
jybz has joined #openocd
<jancoow>
PaulFertser reset_config connect_assert_srst is not executed before checked IDR
<jancoow>
afaik?
JoseT has joined #openocd
JoseT has quit [Quit: Client closed]
<Haohmaru>
btw, if this cold-plugging somehow gets fixed, i want to be informed please, as i'd wanna use it
<PaulFertser>
jancoow: reset_config connect_assert_srst is a configuration. It tells OpenOCD to always pull SRST down before trying to talk to the target.
<PaulFertser>
A proper Cortex-M target should have SWD fully working under reset. Like STM32 MCUs.
<jancoow>
PaulFertser I do get the error 'Warn : 'srst_nogate' reset_config option is required'
<PaulFertser>
jancoow: that's correct, this can work only with targets which continue talking over SWD or JTAG with SRST asserted. So "srst_nogate" is required.
<jancoow>
PaulFertser but that results in Error: BUG: can't assert SRST
<PaulFertser>
jancoow: what adapter do you use? And you need to tell OpenOCD that you actually have SRST with "srst_only" option.
<jancoow>
PaulFertser thanks, it seems to be working!
<jancoow>
reset_config srst_nogate
<jancoow>
reset_config connect_assert_srst
<jancoow>
reset_config srst_push_pull
<jancoow>
this seems to be working
<PaulFertser>
Hm, but why srst_push_pull? Is your adapter a weird one?
<PaulFertser>
And are you sure it helps to talk to a locked saml target now?
<jancoow>
hmh, it seems to be working without push puull as well
<jancoow>
i've got an atmel ICE
<jancoow>
it's not locked. We set the debug pins as tri-state in our application code to reduce power consumption
<jancoow>
(and possible weird behaviour)
<jancoow>
now we can simply check on boot if the debug probe is connected and if so don't reconfigure the pins
<PaulFertser>
Atmel ICE has a proper SRST output capable of open drain as it should.
<jancoow>
gotcha
<jancoow>
so, what exactly does reset_config connect_assert_srst and reset_config srst_nogate do?
<jancoow>
and why am I able to do a cold-start now?
<PaulFertser>
srst_nogate tells OpenOCD that the target is capable of communicating over JTAG/SWD with SRST asserted. connect_assert_srst tells OpenOCD to always when connecting first pull SRST low, then establish debug connection with the target, then deassert SRST.
Haohmaru has quit [Quit: saionara]
<jancoow>
Gotcha!
<jancoow>
That's why I had trouble sometimes hot connecting when the device was in sleep because it doesn't reset first
<jancoow>
Connecting is much smoother now
<jancoow>
However the advantage is when a device was acting weird I could attach without letting the device reset which was cool and impossible with atmel studie
<jancoow>
Studio*
<PaulFertser>
That's why OpenOCD doesn't enable connect_assert_srst by default.
<PaulFertser>
To let you inspect the current state if at all possible.
<PaulFertser>
antto: it looks really nice visually :)
<PaulFertser>
antto: I'm not sure all people would appreciate having that pull up there, what's the rationale for it?
<antto>
R32?
<PaulFertser>
Yes
<antto>
i don't remember but i think i must've read somewhere that maybe RST must be pulled up always
<antto>
not sure
<antto>
but i made it a relatively big value
<antto>
another possible explanation is: "i wasn't sure if there should or shouldn't be a resistor there, so i added it, i can always mark it DNF"
<PaulFertser>
Then attaching your debugger /might/ affect reset operation even when it's not doing anything.
<PaulFertser>
That might be confusing to end user I think.
<antto>
is it absolutely better in all scenarios to not pull up RST in the debugger?
<PaulFertser>
Also, given you have an 1.8 V target you'd be limiting the maximum current you sink to reset it to less than 18 mA, right? That's probably OK in most cases but feels like an arbitrary restriction which might fire in some edge case.
<PaulFertser>
antto: well I can imagine having a board where there's no integrated RST pullup anywhere and instead of adding it externally I just count on having one in the debug adapter since it's a prototype anyway and I only use it with debug adapter.
<antto>
that board won't work without the debugger attached tho, right?
<antto>
so that's not a very legit scenario, thus i guess i should DNF that resistor
<PaulFertser>
That imaginary board in my head is flaky without that debug adapter :)
<antto>
as for the other thing, i can't find my notes from when i "designed this", but i think i remember that 1.8V was not gonna be supported due to one of the other logic ICs
<PaulFertser>
I'm also surprised you're using a BJT there but that shouldn't matter much. If I was developing an adapter I'd take a close look at Olimex or other well-known circuits "for inspiration".
<antto>
huh, what about it?
<antto>
i mean, what would you put there instead?
<antto>
it's kinda too late now since this is 2nd board revision already >:(
<PaulFertser>
A FET feels natural, no?
<antto>
oh
<antto>
well i don't schprachen ze transistors much
<antto>
but NPN and PNP simple transistors i find easier to simulate in falstad/circuit
<antto>
when i insert a FET there, i don't know wtf's going on
<antto>
while the default "transistor" model in falstad at least to me seems close enough to reality that so far i've "designed" transistor circuits via trial-and-error in falstad and in reality they worked
<antto>
BC847 is the typical transistor i use for all kinds of things and as far as i know, with these you can drive in one direction and "Hi-Z" in the other direction so i slapped it there
<antto>
most of this circuit was made up in falstad
<antto>
what is this ^
<antto>
i mean, first, i wouldn't know what kind of fet to use, second, i wouldn't know if the FET model in falstad would represent it close, or i'd have to alter the parameters
<antto>
and if i have to alter the parameters: third, i don't know wtf i'm doing
<antto>
thus i tend to stick with what's familiar to me
<antto>
i don't feel like ruining the whole board with a lousy experimental FET circuit ;P~
<cambrian_invader>
FETs are really easy to design IME since they don't require any current to turn on/off other than the current to charge the gate
<antto>
cambrian_invader, okay, but i don't understand transistors in general
<cambrian_invader>
so you don't have to model them too much especially for switching applications where you're not in the linear region
<antto>
what i do know is that 98% of the time i make some circuit in falstad with transistors, and the same circuit in a real board - the two more or less work the same
<antto>
which means if i can make it work in falstad, it probably will work, so that feels safe and i go with it
<antto>
and i know a few models.. BC847 for NPN, and i forgot what was the PNP one (it's mentioned in the datasheet since they are twins)
<antto>
and i also know some dual versions of those
<antto>
that's plenty enough for my silly circuits so far
<antto>
PaulFertser, what is this thing you've put on that link?
<antto>
i see a FET, some 24 volts, and some other stuff
<antto>
but i don't like these pauses between the bytes
<PaulFertser>
antto: I made that to show a pal that in his schematics no additional 9 V power supply is needed to control that FET (its gate voltage should not go above 12 V or so).
<antto>
i've tried FETs in falstad, i just stay away from them since i know even less about tham than i know about transistors... and i know almost nothing about transistors
<PaulFertser>
Well, T in FET is for Transistor ;)
<antto>
i would probably accept them if the simulator actually has a legit model of a real FET and that's the FET i am going to use for real
<antto>
but this smells more like SPICE-grade simulation