<jancoow>
PaulFertser hey my workday was over and didn't check irc anymore
<Haohmaru>
that's a sin
<jancoow>
PaulFertser mhm, we never added this pull on all our products and never had reliabily issues while producing and programming those
<jancoow>
but apperently we never set the security bit so the DSU alwasy was on and could trigger
<jancoow>
`Early datasheet versions did not have the SWCLK pull-up recommendation and I had no problems with designs that did not include it. However, there is likely a good reason this recommendation was added. The related link that's missing might be about the section "Operation in Noisy Environment".` ah they added it later in a revision
<Haohmaru>
i found out why i had gaps between the SPI bytes, it was when MSSEN is enabled (that is on the SPI in m*ster mode, the automatic sl*ve-select control)
<Haohmaru>
i guess i'm close to actually attaching a target to my wanna-be-debugger
<jancoow>
PaulFertser that actually works?!
<jancoow>
We configure all pins as tri-state now after boot in order to eliminate all bugs regarding leakage current. But in the erata is shown that the SWD pins sometimes reconfigure itself..
<jancoow>
which might lead to our products sometimes come in a random state of 80ua (happens occasionally)
<Haohmaru>
often the programming/debugging pins are a bit more different than the others
<Haohmaru>
sometimes even some other pins like USB pins or so
<jancoow>
ye usb pins same, also errata
<jancoow>
it's possible the pull resistors are magically enabled after reset (while it should not according the datasheet)
<jancoow>
that's why we don't trust on the reset controller configuring all pins/port anymore and we do it ourself in software
<jancoow>
because 80ua will kill our battery in 6 months..
<jancoow>
our normal standby power is on average 2.2ua
<jancoow>
(with peaks from the brownout check tho)
<Haohmaru>
luckily i rarely have to make batter-powered stuff
<jancoow>
hehe
<jancoow>
we mainly do
<Haohmaru>
i have an overclocked SAME54 at home running 24/7 since years
<jancoow>
with 5-7 years battery life
<jancoow>
but the saml21 is so overpriced and the samr35 really outprices itself in the market
<jancoow>
but redesigning everything around a stm32 cost so much development
<Haohmaru>
i find atmel stuff more noob-friendly btw
<jancoow>
ye?
<jancoow>
datasheet is pretty good in general
<Haohmaru>
for contrast, look at NXP
<Haohmaru>
i wanted to have their 500-600MHz chip on a board, but even after registering on their site, downloading the datasheets and chip configurators, i couldn't figure out wtf's going on
<Haohmaru>
so i gave up
<jancoow>
Haohmaru you know how to set the reset config from gdb?
<Haohmaru>
what do you mean?
<jancoow>
so I tested the theory of PaulFertser and setting reset_config to: reset_config srst_only srst_gates_jtag connect_deassert_srst
<jancoow>
will generate a external reset
<jancoow>
however then cold-plug is not working anymore obviously
<jancoow>
so I first need to cold-plug and then change the reset configuration
<jancoow>
but that doesn't seem to be a valid command
<jancoow>
braunr yes but I need to change the reset configuration
<braunr>
i don't think you do
<jancoow>
I do
<braunr>
or is it because openocd itself can't identify the hardware ?
<braunr>
i think i remember such cases yes
<jancoow>
I want to create a hardware reset with the reset pin instead of software reste
<jancoow>
reset*
<braunr>
in which case you can't send openocd commands, since openocd can't init
<jancoow>
and PaulFertser had a theory why cold-start works with `reset_config srst_nogate connect_assert_srst`
<Haohmaru>
you've enabled the Security bit?
<jancoow>
in development no
<Haohmaru>
so what was the problem then? disabled the SWD pins?
<jancoow>
yes
<jancoow>
put them to floating ;)
<jancoow>
(tri-state)
<Haohmaru>
and the only way to attach a debugger is very soon after a reset, or during a reset?
<PaulFertser>
jancoow: usually tri-stating pins are bad wrt leakage current, I think for power saving all pins should be pulled (can be internally). Do you have a quote from your datasheet that says otherwise?
<jancoow>
correct, in the startup of the code we check if debugger is connected and if so we don't put them in tri-state
<PaulFertser>
jancoow: I mean it's _always_ bad to tri-state.
<jancoow>
PaulFertser atsaml default put them all in floating mode after reset. This means input disabled, output disabled, everything is decoupled
<jancoow>
disconnected*
<jancoow>
also the input buffers are disconnected
<PaulFertser>
jancoow: my point is that there should not be any sensible reason to disable SWD ever in your case, unless I'm missing something important.
<braunr>
eww
<Haohmaru>
right, thus you need the debugger to do an external reset before talking to the chip
<PaulFertser>
jancoow: you should be able to change reset_config at runtime at any moment with gdb "monitor reset_config ..." command.
<jancoow>
ah with monitor, thnx
<jancoow>
PaulFertser well.. we expierence a leakage current of 80ua on some products and we think it might trigger the DSU on the pins. It's also in the erate something vague that out of standby it re-configures the mux of those pins
<Haohmaru>
didn't i say this last time? any command you send with "monitor <xyz>" from gdb would be sent as "xyz" to openocd
<jancoow>
but it rarely happens
<jancoow>
so it's a wild guess it somehow enables the DSU and the power leakage is gone after reset of the device
<jancoow>
Haohmaru sorry I must have forgot
<Haohmaru>
or maybe i said it to someone else
<Haohmaru>
"mon <xyz>" for short
<PaulFertser>
jancoow: with SWD pulled up and all the other pins also having pulls one way or the other there shouldn't be any leakage. Leakage occurs when a pin is in input mode and it's actually floating, thus triggering input circuits.
<jancoow>
Haohmaru i have a lot of monitor in my startup script, i thought this was a configuration change for openocd so i didn't think about using montitor
<jancoow>
PaulFertser but the input circuit totally disconnect on the atsaml
<PaulFertser>
jancoow: how does leakage happen for your via SWD pins then?
<Haohmaru>
it's commands to the "gdb server" .. and in this case, openocd plays the role of a gdb server
<Haohmaru>
while gdb plays the role of a client
<Haohmaru>
so with "monitor" you send commands to the server (openocd)
<Haohmaru>
remember, this is "remote" debugging
<Haohmaru>
btw, are there commands to supply power to the target?
<Haohmaru>
or is this too fancy for openocd
<PaulFertser>
jlink has custom command for that
<Haohmaru>
is it usable thru openocd i mean?
<PaulFertser>
Yes
<Haohmaru>
cool
<jancoow>
PaulFertser we see exactly the same power consumption when the debugger is active
<jancoow>
so we have a theory that the debugger enables in the field somehow
<jancoow>
that including some other theory that some devices totally goes silent while we have multiple protections build in, but we also have a breakpoint halt when a reset happens if the debugger is connected according the software
<jancoow>
so this is a theory for now and for our current production we want to apply those changes
<jancoow>
and now with the datasheet recommending a 1k for "reliable" operations, it seems something is up with the pin
<PaulFertser>
jancoow: the debugger when you run OpenOCD for the first time will enable some debug circuity inside (OCD) so that might raise the consumption.
<jancoow>
PaulFertser correct, that's what we see
<jancoow>
and this power consumption is equal to the devices in the field having randomly this
<jancoow>
either this is due the specific pcb layout, I can see that VSW is running on the opposite of the SWD lines..
<PaulFertser>
jancoow: now that's strange, and it's highly unlikely to be caused by SWD floating. I think why they suggest to have that pull up on SWCLK is because of the silly way to enter that special cold-plug mode, they want to avoid ever seeing SWCLK low on reset (including watchdog reset) because that would make the device stuck for sure.
<jancoow>
PaulFertser we don't put SWD or SWCLK to floating on our previous batches (20k+ devices)
<jancoow>
but we neither enabled the security bit to prevent hot plug mode
<jancoow>
also with putting them to float I also disabled muxing them to the debugger
<jancoow>
(so i configure and detach the pins to anything inside)
<PaulFertser>
jancoow: enabling OCD circuity inside is much more than just few random transitions on the bus, can't happen accidentally.
<jancoow>
also the cold plug mode?
<jancoow>
seeing the swclk low on reset?
<PaulFertser>
Oh, that I can imagine happening but not with you have external pull on SWCLK.
<jancoow>
we don't have an external pull on swclk
<jancoow>
it's apperently something added later in the datasheet
<PaulFertser>
:(
<jancoow>
again, this are just theories
<PaulFertser>
Sucks when a problem can't be reproduced in a lab :/
<PaulFertser>
jancoow: but do you have a workaround good enough for now with that "wrong" reset config at openocd startup and then changed to the correct one later?
<Haohmaru>
i love it when "problem goes away when oscilloscope is attached"
<PaulFertser>
You can also just add something like a pre/post-examine hook for that. Actually, any event should be good, they all happen after initial connection is attempted.
JakeSays has joined #openocd
JakeSays_ has quit [Ping timeout: 260 seconds]
PaulFertser has quit [Read error: Connection reset by peer]
antto has quit [Remote host closed the connection]
h4x0riz3d has joined #openocd
PaulFertser has joined #openocd
<jancoow>
PaulFertser yes, your workaround works great! I start with this 'reset_config srst_nogate connect_assert_srst' which will perfectly work in cold-plug mode
<jancoow>
and then switch to 'reset_config srst_only srst_gates_jtag connect_deassert_srst'
<jancoow>
after programming my device detects an external reset
<PaulFertser>
Nice
<Haohmaru>
hm, is this something that could work in same54 for the security bit situation?
<PaulFertser>
Unlikely
<PaulFertser>
Haohmaru: why do you bother?
<Haohmaru>
it's a feature of the chip.. sounds cool on paper
<PaulFertser>
Then it would be cool to have it in OpenOCD.
<Haohmaru>
enabling it is easy
<Haohmaru>
it can be enabled via the firmware even (in fact, that's how i did it to test it)
<Haohmaru>
but then you can't do anything with that chip with openocd, it's like "bricked"
<jancoow>
the security bit I can set for the saml21 i believe
<jancoow>
we do set bootprot
<Haohmaru>
that one was related too
<PaulFertser>
My point is that if it's a cool feature please make OpenOCD play nice with it.
<Haohmaru>
who am i to make openocd do anything ;P~
<PaulFertser>
In my world disabling SWD access or readout protection isn't cool.
<Haohmaru>
PaulFertser, the feature is about making your firmware less easy to be stolen, supposedly
<PaulFertser>
Haohmaru: that's bad and wrong idea, firmware should be freely readable.
<Haohmaru>
shall i give you my $boss on the phone?
<PaulFertser>
I was telling the same to my bosses, seriously.
<Haohmaru>
but i might also want this for a personal project
<Haohmaru>
because i know some f*ckers will immediately steal it
<Haohmaru>
if it's that easy i mean
<PaulFertser>
Aren't your personal projects meant to give joy to the others?
<PaulFertser>
You can't steal what's already nicely freely available for copy and improvements.
<Haohmaru>
well, supposedly they are, but then i end up being insulted by a pile of people about some design decisions
<Haohmaru>
but this is a long story and too off-topic for here
<Haohmaru>
mmmm, there are "fast" 16bit PISO shift registers, why didn't i know about this.. maybe i could've pulled off SWD with 1 SPI and some of these
Hammdist has joined #openocd
<Hammdist>
hey all. I am design a board with an FPGA and an FTDI adapter chip and the latter enumerates on USB and I am able to scan the FGPA with openocd (hurrah). I have svf file for FPGA. how do I send the svf to the FGPA using openocd?
<Hammdist>
I am using JTAG btw
<Haohmaru>
svf?
<Hammdist>
yes, output from ecppack of an ECP5 FPGA cfg file
<Haohmaru>
oh, no clue
<karlp>
well, what have you tried?
<PaulFertser>
Hammdist: just the "svf" command should do the trick :)
<PaulFertser>
Haohmaru: fyi, basically SVF is just a list of JTAG low-level operations to perform, it does scans and can check the resulting values against a masked constant.
<Hammdist>
well by now I have, in addition to ftdi ... commands to configure the ftdi, reset_config ..., jtag newtap ..., init, svf, exit. but the FPGA does not ignite the LED it's supposed to. is there anything further needed to take the FPGA out of reset or something?
<Haohmaru>
when people say FPGA - i should just stfu ;P~
<PaulFertser>
Hammdist: no, shouldn't be, it should be all in your SVF.
<PaulFertser>
Hammdist: probably you need to tick some options in that ecppack or something.
<PaulFertser>
BTW, why do you need non-default reset_config? TRST is an optional signal for JTAG.
<PaulFertser>
Usually SVF generators add some meaningful comments inside, they can be useful too, I suggest you try reading it in a text editor.
<Hammdist>
I needed reset_config to talk to an STM32 earlier. maybe it's not needed for the FPGA. probably doesn't harm anything to leave it there
<PaulFertser>
Hammdist: depends on what you set and what you connect.
<PaulFertser>
Hammdist: if e.g. you tell OpenOCD you enable TRST while in fact you do not have it connected it does harm.
Deneb has joined #openocd
<Hammdist>
got the flashing to work. my real issue was that I had OPENDRAIN=ON on some LEDs that I forgot were actually active high
<PaulFertser>
That explains it :)
<PaulFertser>
Cool!
das has joined #openocd
<das>
hello I've tried rebuilding the latest OpenOCD from the git instead of using the Debian package because I had this error "Error: Invalid ACK (4) in DAP response"
<PaulFertser>
das: please use some pastebin to show full -d3 output.
<PaulFertser>
das: ah, you have issue building? What exactly?
<das>
it's an original JLink which i've used dozens of times
<PaulFertser>
jancoow: interesting!
<das>
the speed is auto set to low, 100KHz
<jancoow>
PaulFertser i remember this batch was pretty good anyways. I mean, we allow everything <6ia
<jancoow>
6ua *
<jancoow>
but if for examples a drop of a diode + ldo + mcu are in the more worse side of the spec it could be not good
<PaulFertser>
das: is it same consistent result with e.g. 1 MHz?
<PaulFertser>
das: it might indeed mean the debug circuity doesn't want to talk to you at all for whatever reason.
<das>
yeah JTAG could be locked but this line surprises me as it seems to indicates it does discover smth: "am335x.jrc tap/device found: 0x2b94402f (mfg: 0x017 (Texas Instruments), part: 0xb944, ver: 0x2)"
<PaulFertser>
Well, JTAG is one thing, ARM Debug module is another.
<das>
adapter speed 1 through 10000 doesn't seem to have any effect
<PaulFertser>
JRC is "JTAG Router", a device which allows you to attach and detach individual taps to the chain.
<das>
ha
<PaulFertser>
I'm not familiar with AMX335x, probably you need to study its datasheet about the debug topics.
<PaulFertser>
das: also, what is the target doing at that moment you're trying to connect to it? Have you tried stopping in U-Boot or something?
<das>
I've got another dev board somewhere in the pile that has an am3352 I'll try it tomorrow
<das>
I've tried with the target booting (while loop) and the target booted
<das>
same result
<PaulFertser>
das: do you not have control over target's firmware?
<das>
PaulFertser: not to this board, it's a blackbox for now
<PaulFertser>
das: OK, I see. Most probably the debugging is locked somehow.
<das>
PaulFertser: there's a good chance it is indeed but I'm also unsure if I can distinguish a failed setup from a locked JTAG
<PaulFertser>
das: you can also try checking with jlink proprietary software
<das>
PaulFertser: good thinking, IIRC there are GUIs for Windows, I'll try this tomorrow
<das>
PaulFertser: thanks for the guidance
<PaulFertser>
das: you do not need a GUI to check, and do not need windows either.
<PaulFertser>
Should be all available for you to try with jlinkcommander.
<PaulFertser>
I hope you figure it all out eventually, welcome.
<Hammdist>
suppose I just want to read two slow-varying bits from the FPGA in a kind of one-shot mode. can I ignore everything else and just feed the bits into JTDO1, JTDO2?
<Hammdist>
what would the openocd incantation for reading these bits look like?
<Hammdist>
to be clear I -don't- want to use that scala code (I'm writing mainly pure verilog), it's just for illustrating the JTAGG primitive
<PaulFertser>
Hammdist: hm, that probably wouldn't be a good idea. Have you seen the JTAG state machine diagram?
<PaulFertser>
Hammdist: in OpenOCD you can do "irscan" and "drscan" commands for stuff like that. But you still probably want to have that state machine implemented on the target I guess.
<Hammdist>
is the JTAG clock free-running? or does it only run when commands are being sent?
<Hammdist>
the signals are passing through 3-stage synchronizers
<Hammdist>
as long as one discards 3 initial bits the next bit should be legit
<PaulFertser>
OK, that might work I guess. In OpenOCD you can do irscan.
<Hammdist>
ofc one cannot transfer significant amounts of data with this. it just provides 2 "virtual LEDs" basically
<Hammdist>
I think one can extend this technique of ignoring the state machine to implement arbitrary number of virtual LEDs with some cooperation from host software. the idea is to send N+1 zeros followed by N bits of virtual LED data. then read 4N+4 bits and do some work to sync up in the host software
<Hammdist>
well the N+1 zeros must be "framed" by 1s to be recognized unambiguously. missed that at 1st