JakeSays has quit [Remote host closed the connection]
JakeSays has joined #openocd
nerozero has joined #openocd
defiant has joined #openocd
Hawk777 has joined #openocd
noarb has quit [Ping timeout: 276 seconds]
noarb has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
kraiskil has joined #openocd
PlasmaHH has joined #openocd
<PlasmaHH>
Hi, there is a patch waiting to make the ft232r driver support swd .... https://review.openocd.org/c/openocd/+/6978/2..9?tab=comments ... anyone knows whats the actual holdup/status there? it would come in really handy for me right now ^^
<Haohmaru>
i think the general problem is too few people are involved
<PaulFertser>
PlasmaHH: hey
<PaulFertser>
PlasmaHH: take it, rebase on current master, test, push updated version there keeping Change-Id.
<PaulFertser>
That might allow the progress.
<PaulFertser>
Since original author decided to not keep pressing on merging it.
<Haohmaru>
perhaps, instead of using "AI" for making stupid influencers, someone should use it to make volunteers for code review ;P~
<PlasmaHH>
Haohmaru: we are currently integrating ai into the code review process of our company, its an.... intresting processs
<Haohmaru>
huehue
<Haohmaru>
i guess it's still too early
<PlasmaHH>
PaulFertser: any documentation on how to do these steps exactly with gerrit? I am totally unfamiliar with its workflow and would not have thought about being able to push into someone elses merge reequest...
<PlasmaHH>
Haohmaru: well the capabilities are there and there are also useful results, however the amount of, say, outliers is still pretty high and getting around those is important
<PlasmaHH>
you don't gain much if you have to work through tons of hallucinated comments...
<Haohmaru>
make another "AI" that reviews the reviewers x_x
<Haohmaru>
soon: aioverflow.com
<PlasmaHH>
well, in a sense that is how reasoning models work
<PlasmaHH>
the part where we most struggle with at the moment is giving the model the right amount of code context
<Haohmaru>
yeah i was kidding but more seriously, to make a useful code review, you'd have to basically be a developer of that project, you have to be familiar with what's going on, and not only that, but probably you have to also consider how other requests for changing the code will affect the code you're reviewing now and how all of that fits into the big picture x_x
<PlasmaHH>
well, yes and no, you are describing the ideal one, but having another "pair of eyes" that only focusses on other things like coding guidelines, good c++ or whatever context they know about is arelady really helpful
<Haohmaru>
otherwise the "AI" will be looking thru a tiny hole and could just suggest "this variable name is unclear" "this bracket should be on a new line"
<Haohmaru>
sure
<PlasmaHH>
there are some that propse when setup right such a system could automatically merge when all other things are fine (unit tests etc.) but I think htat might be too early, but who knows, they are working on systems that have 10mio tokens of context, that might work
<Haohmaru>
btw, i wish i knew about these flip-flops, it seems you could make your own, variable-count shift register out of them
<PlasmaHH>
flip flops arent exactly new ;)
<Haohmaru>
yes, but i'm generally unfamiliar with piles of things ;P~
<Haohmaru>
this is for the SWD context, as i made a SWD debugger board where i used a combination of 3 SPIs to reproduce the SWD signals
<PlasmaHH>
sounds... intresting?
<PlasmaHH>
I plan on integrating an ft2232h into my next big board...
<PlasmaHH>
its a shame that the ft4232h doesn't have 4 "full" channels
<Haohmaru>
i was thinking of using shift registers, but to solve that i would've had to use some help, probably i would've had to carefully write a simplified model of the shift register (in C++ for example) and then fiddle with combinations of things untill i get it working in this form, then i can make it into a circuit
<Haohmaru>
i got it working with this 3xSPI scheme, and the next step is actually the whole daplink side of things, that's where my eyeballs entangled and it's left gathering dust
<PaulFertser>
PlasmaHH: hm, there's the HACKING document that describes the usual steps. And in general you just use git as usual, just keep the Change-Id tag in the commit message and push an updated patch (just a single commit on top of current master branch) to refs/for/master.
<PaulFertser>
PlasmaHH: I can clarify more but I need specific questions from you :)
<PaulFertser>
So you just fetch the code with the latest version of the patch from Gerrit (it gives you a link) , cherry-pick on top of master, fix conflicts manually, test etc.
<Haohmaru>
it'd be nice if openocd had a hardware debugger project, i see openocd has code to support 23490874239 different existing things that play the role of the hardware debugger, would've been nice if there was a debugger specifically made for openocd ;P~
<PlasmaHH>
Haohmaru: what would that mean, being specifically made for it?
<Haohmaru>
code-wise it'd be easy to deal with, it'd have features that fit well with openocd, it'd be decent, if someone is new to all of these things and needs to equip himself with a debugger and has no clue which one to choose - you could recommend picking this one ;P~
<Haohmaru>
i don't know, might be a dumb idea
<PlasmaHH>
well I think it should also be cheap then...
<Haohmaru>
of course
<PaulFertser>
PlasmaHH: that ft232r code looks to be in reasonable shape, I'd say it just needs someone motivated to finish the process.
<PlasmaHH>
I mean if you want tohave something really easy to use then use a blackmagic or so, cut out the need for openocd ;)
<Haohmaru>
no $1000 sh*t pls
<Haohmaru>
but openocd is nice
<PlasmaHH>
PaulFertser: yesterday after fixing a few things I got that branch to at least compile ... might have some time in between meetings today to try rebasing it
<Haohmaru>
if some new chips come around, you could always teach openocd how to deal with them, if all of that knowlage has to be inside the hardware debugger, then you have to deal with firmware
<PlasmaHH>
Haohmaru: it sure is, but from a usability pov if you get the same features you want wihtout it...
<Haohmaru>
and openocd can grow a lot, you can't have a very very very fat firmware on a hardware debugger
<Haohmaru>
unless it's a SBC ;P~
<PaulFertser>
PlasmaHH: hm, but it passed CI back then so it was compilable for sure.
<PlasmaHH>
PaulFertser: with whatever compiler was used back then, not with a more modern gcc 14
<PaulFertser>
PlasmaHH: was it giving actual errors or just warnings treated as errors?
<PlasmaHH>
PaulFertser: warnings treated as errors
<PlasmaHH>
mostly calloc parameter swaps
<PaulFertser>
OK, that's to be expected then, configure has a switch to disable it for cases like that (when you want to test old code for whatever reason).
<PlasmaHH>
ah ok, will keep that in mind
<PlasmaHH>
Haohmaru: well being able to quickly use new stuff is one of the big selling points of the expensive probes...
<Haohmaru>
huh
<PlasmaHH>
they often support them before the actual hardware is available
<Haohmaru>
i thought supporting a new chip on a computer program (openocd) would be easier than on a standalone hardware debugger
<Haohmaru>
ah wait, you mean the big fat $$$debuggers
<PlasmaHH>
yep
<PlasmaHH>
commercial grade hw
<Haohmaru>
of course, that's not a fair comparison
<PlasmaHH>
what I would want from your openocd hw probe would probably mean a mix of firmware and openocd code... things like being fast, or supporting flash breakpoints
<Haohmaru>
the point of having a program on the computer is so that the hardware debugger doesn't have to be super clever, it just has to know how to do the boring things that are awkward for the PC to do
<Haohmaru>
yes, "fast" is obviously one of the things, i have no idea about flash breakpoints
<PlasmaHH>
I find them the single most useful thing when using segger probes
<Haohmaru>
*shrug*
<PlasmaHH>
per default setting some for all kinds of handlers I run out of hardware breakpoints almost immediately
<Haohmaru>
i'm not actually familiar with the debugging process too much
<PlasmaHH>
but you know what breakpoints are? ;)
<Haohmaru>
i use breakpoints, i just don't know exactly how they work
<PlasmaHH>
on most hardwawre its some special function registers that you fill in with the address you want to break on, and usually you have a rather limited amount like 4
<Haohmaru>
i guess the chip itself has slots for addresses (in the program space) and when program counter "moves" and the new address matches one of the values in those slots - it freezes and tells the debugger
<Haohmaru>
and if you run out of slots but need to have more breakpoints, then i guess, you'd have to do it in a much more awkward way
<Haohmaru>
you'd have to maybe read the program counter and advance the MCU with just 1 instruction and read it again
<PlasmaHH>
yes, thats where the flash breakpoints come in... almost every architecture has a breakpoint instruction with the smallest encoding possible so you can replace the code by that instrution
<Haohmaru>
oh wait
<Haohmaru>
does this mean you modify the firmware?
<Haohmaru>
i mean, the debugger modifies the firmware
<Haohmaru>
replaces the instruction at the address with a breakpoint instruction?
<PlasmaHH>
indeed
<Haohmaru>
huh
<Haohmaru>
that'd be nice if the program is in RAM, but if it's in flash
<Haohmaru>
so if you unplug the debugger suddenly - you're MCU is left with a modified firmware ;P~
<Haohmaru>
* your
<PlasmaHH>
yes that can happen
<PaulFertser>
PlasmaHH: I see no reason why flash breakpoints can't be implemented in OpenOCD itself, it doesn't need any special support from the adapter.
<Haohmaru>
true
<PlasmaHH>
Haohmaru: and then you restart your ide and suddenly it stops at a breakpoint you never set in your IDE and you wonder
<Haohmaru>
in "our" scheme, openocd is where the "brains" are, not the hardware adapter
<Haohmaru>
the hardware debugger just needs to deal with the electrons fast and properly
<PlasmaHH>
PaulFertser: indeed, in theory this is possible ( which is what visualgdb can do for stm32) but doing it in the adapter would be much faster and much more transparent to the host
<PlasmaHH>
many ways to skin the cat
<PaulFertser>
One usually is using GDB or other debugger anyway, not OpenOCD directly, so that'd be as transparent.
<Haohmaru>
in my case i tried to make the SWD faster, so i came up with the 3xSPI scheme which in theory should allow up to 24MHz SWCLK
<Haohmaru>
i had no idea about flash breakpoints but the point is, for a "openocd hardware debugger" it should be designed by someone better than me, someone who is more familiar with the things involved
<PlasmaHH>
some chips like the h7 dual core versions even have hardware support for flash memory patching without patching flash memory
<PlasmaHH>
which on the h7 is really necessary due to its ridiculous page sizes
<Haohmaru>
how much is it?
<PlasmaHH>
128k
<Haohmaru>
wot
<Haohmaru>
kilo _bytes_ ?
<Haohmaru>
i thought the 8KB page size in the same54 is "big"
<PlasmaHH>
yeah kbytes... so if you would want to use the traditional way of patching that you would need to erase one 128k page and rewrite it just to change two bytes ^^
<PlasmaHH>
which is why they added that extra "overlay" thing where you can configure some addresses where it fetches from ram instead of flash to do those patching operations
<PlasmaHH>
for whatever reason it seems to work only on the dual core version
<Haohmaru>
yeah that's what i meant, it's nice if the program is in RAM but otherwise, even on the 8KB page size i would rather be aware of this "feature" and decide where i wanna use it and how often
<PlasmaHH>
you get used to re-flashing the firmware often ;)
<Haohmaru>
i do reflash often sometimes, but i am obviously aware of it
<Haohmaru>
it be kinda not good if some such feature is silently enabled by default and i'm not aware of it
<PlasmaHH>
I think if you use the segger gdbserver then you can't even tell. I never bothered to check anyways, why would I care
<Haohmaru>
i'm not super wealthy ;P~
<Haohmaru>
these chips cost $$$
<PlasmaHH>
PaulFertser: you dont happen to be very familiar with the mpsse based ftdi driver?
<PlasmaHH>
Haohmaru: yeah obviously I use them only at work *cough*
<Haohmaru>
well i make boards at $home too
<Haohmaru>
i mean, i design boards, i get them fabbed properly afterwards
<Haohmaru>
and then they gather dust
<Haohmaru>
i went to wrestle with the daplink side of the firmware and i got lost there and left it
<Haohmaru>
but in the mean time i managed to recompile a more recent version of the normal daplink for my kamami zl33prg debugger and it worked, the newer version uses USB bulk and there's a slight improvement in speed on one of the targets (i forgot which)
<Haohmaru>
hm, on both actually, just the speed is different between the two.. CM0+: 6.232 -> 19.5, CM4F: 16.15 -> 37.421
<PlasmaHH>
the major feature I need speed for is my "single step instruction tracing" thing
<Haohmaru>
that's KiB/s firmware write speed via openocd
<PlasmaHH>
with a slow debugger this becomes even slower than it already is ^^
<Haohmaru>
no clue what that is
<PlasmaHH>
thats what the text is for to explain :P
<Haohmaru>
yeah "xi is like si" ... that answered 101% of my questions
<Haohmaru>
it's like that joke "what's a xi?" "well, do you know what an elephant is?" "yes, of course i know what an elephant is." "well, xi is NOTHING like an elephant."
<PlasmaHH>
if only that text had more than four words
<Haohmaru>
wait, is that "si" as in the gdb CLI command for "step into" ?
<PlasmaHH>
yep
<Haohmaru>
okay i've used dbg via CLI two-three times
<Haohmaru>
99% of the time i just use it via C::B
<PlasmaHH>
via what?
<Haohmaru>
Code::Blocks, my IDE
<Haohmaru>
because i'm a GUI click-clackz0r, not a CLI h4x0r
<PlasmaHH>
oh ok, that thing is still alive?
<Haohmaru>
i've tried a gdb TUI once or twice too, it was... an option too
<Haohmaru>
well, it still works and comes in debian
<PlasmaHH>
I dont like the tui at all
<PlasmaHH>
even thinking about rewriting something for it in textual
<Haohmaru>
and i can use the same IDE for anything from "PC program" to "firmware" projects on several different kinds of targets
<Haohmaru>
oh, and wxSmith for when i wanna make a wx program ;P~
<PlasmaHH>
I never found anything in the IDEs good enough to abandaon a well working editor environment
<Haohmaru>
because you're a h4x0r probably
<Haohmaru>
you probably use one of those vim/emacs kinds of things
<Haohmaru>
that's not a text editor for mere mortals, that's for h4x0rz
<Haohmaru>
this is why i use an IDE, with toolbars and buttons and dialogs
<PlasmaHH>
I am too impatient to use a mouse :P
<Haohmaru>
i don't use the mouse when manipulating text, except for when i wanna do multi-line carret tactics, which i don't know how to do via keyboard
<PlasmaHH>
carret tactics? are you in war with your code?
<Haohmaru>
i use shift+del, shift+insert a lot
<Haohmaru>
yes, i'm a code butcherer, the code often misbehaves
<Haohmaru>
home, end too, shift+home, shift+end
<Haohmaru>
but sometimes i also double-click on a variable name with the mouse ;P~
<PlasmaHH>
what do these combos do in your editor?
<Haohmaru>
basically, when i get an idea and i wanna very quickly materialize it before i forget - i throw the mouse away and butcher the code with two hands on the keyboard
<Haohmaru>
shift+del is the same as ctrl+x, shift+insert is ctrl+v
<Haohmaru>
ehm, cut and paste
<PlasmaHH>
ah ok
<Haohmaru>
shift plus arrows or home/end selects and moves the carret
<Haohmaru>
if i've written a line of code but i wanna start over i'd do shift+home and start typing the new text
<Haohmaru>
if might need that line later, shift+home+del
<Haohmaru>
stuff like that
<PlasmaHH>
seems like just yet anothere key sequence
<Haohmaru>
ctrl+x/c/v are for the left hand only
<PlasmaHH>
for me deleting from the cursor to the end of the line is just D (in normal mode that is of course)
<Haohmaru>
the shift+del/ins version is more useful to me, two hands and then shift has a bunch of other things like arrows, home/end which are all in the same location, so two hands, the stupid left hand only has to press the shift key
<Haohmaru>
there's no "copy" version for shift, at least to my awareness, but if i wanna copy with the shift i'd just do shift+del+ins (and i'll loose the selection)
<Haohmaru>
and then there's also the ctrl key which makes moving the carrect jump over "words"
<Haohmaru>
* carret
<Haohmaru>
these tactics work in most "sane" text entry boxes across many programs
<PlasmaHH>
y$ for "copy until end of line"
<Haohmaru>
from silly old notepad.exe on win98 to hexchat's entry box
<Haohmaru>
huh, that'd be shift+end ctrl+c, or shift+end+del+ins
<PlasmaHH>
guess in that sense Dp would work too
<Haohmaru>
and not long ago duckduckgo made something to their searchbox on the main page which f*cks up with my tactics >:(
<PlasmaHH>
I think I saw an interview with don the other day where he explained why its called yank etc. instead of copy/paste in the classical editors
<Haohmaru>
and when the whole program has turned into sh*t: ctrl+end ctrl+shift+home del ctrl+s alt+f4, F**** THIS SH**
<Haohmaru>
because ctrl+a is too simple
<Haohmaru>
the keys should feel your frustration too
<PlasmaHH>
git reset --hard ?
<Haohmaru>
i don't schprachen ze git
<PlasmaHH>
rcs?
<Haohmaru>
wot
<PlasmaHH>
an ancestor to git
<PlasmaHH>
well we can even go back to sccs if you prefer
<Haohmaru>
<nope.gif>
<PlasmaHH>
forward to cvs?
* Haohmaru
presses Redial on that last .gif
<PlasmaHH>
kids these days... svn?
<PaulFertser>
PlasmaHH: not very familiar but I used to know something
<Haohmaru>
let's just hope there's less situations like that ;P~
MGF_Fabio has quit [Remote host closed the connection]
<PlasmaHH>
PaulFertser: since there are many pins unused in the swd case I was wondering if one of them could be used for receiving swo data, that way one would not need the second ftdi chip channel for that (or could use a one channel version)
MGF_Fabio has joined #openocd
<PaulFertser>
PlasmaHH: SWO is self-clocked by the target independently of the interface, so you can't capture it reasobly along with communication of SWD on the same interface.
<PaulFertser>
In certain cases you do not really need SWO though and you can use semi-hosting for bidirectional communication over the debug interface without any additional wires.
<Haohmaru>
one of the options for the SWO was a "normal UART" right?
<Haohmaru>
so it's async
<PaulFertser>
Yes, and normal UART mode can be captured by "the second ftdi chip channel".
<PaulFertser>
Semihosting is kinda neat as it's usually very easy to use but since it's basically "syscall/upcall to host via software breakpoint instruction" the approach has certain limitations.
<PlasmaHH>
one of which is speed
<PaulFertser>
Not all tasks require all speed all the time though, and you can buffer.
<Haohmaru>
i keep using a normal UART (full-duplex typicall) outside of SWD, since the kamami daplink i have does have a UART it's very convenient, i've made an adapter where both the SWD and this extra UART is on the same programming port
<PaulFertser>
Another reasonable approach would be J-Link's RTT, have you considered that?
<PaulFertser>
Polling target memory is possible without halting the target so it's kinda non-intrusive.
<PlasmaHH>
true, though my current application needs minimal timing influence on the real firmware, I cannot afford to stop it for a millisecond to transfer some text
<PaulFertser>
And you can use it with any adapter with OpenOCD.
<PaulFertser>
RTT works without stopping.
<Haohmaru>
hm, that sounds cool
<PlasmaHH>
I have never managed to get a proper setup within gdb to read memory while running, it always barfs at me
<Haohmaru>
is that how you do that sort of statistic where you periodically check the program counter and write it down and then you can sorta see in what places your firmware is "sitting" most often
<PaulFertser>
PlasmaHH: but "mon mdw 0x2xxxxxxx" would work for suer.
<PaulFertser>
PlasmaHH: are you using GDB in that special async mode when trying that?
<PlasmaHH>
PaulFertser: yeah
<PlasmaHH>
but its really unstable with the python api
<PaulFertser>
PlasmaHH: I see, not many people do that so guess bugs do not get exposed much.
<PaulFertser>
PlasmaHH: you can also use Python to talk directly to OpenOCD's RPC port.
<PlasmaHH>
yeah it seems that I am one of the heavy users of their python api...
<PaulFertser>
OpenOCD might need to be fixed a bit to work properly with GDB async, but that'd require someone who's able to reproduce the issue and also willing to work on OpenOCD.
<PlasmaHH>
yeah my swo plugin at the moment talks to some port and relies on external setup... I would like it to be as versatile as possible... tried to integrate me segger rtt but ran into too many issues... would have been nice to have it just be different flavours of getting data through
kraiskil has quit [Remote host closed the connection]
wingsorc has joined #openocd
MGF_Fabio has quit [Read error: Connection reset by peer]
MGF_Fabio has joined #openocd
MGF_Fabio has quit [Ping timeout: 268 seconds]
tsal_ has quit [Ping timeout: 260 seconds]
Haohmaru has quit [Quit: saionara]
tsal has joined #openocd
tsal_ has joined #openocd
tsal has quit [Ping timeout: 244 seconds]
nerozero has quit [Ping timeout: 276 seconds]
shibboleth has joined #openocd
kcxt has left #openocd [>,<]
diddly has quit [Read error: Connection reset by peer]