WormFood has quit [Remote host closed the connection]
WormFood has joined #openocd
jybz has joined #openocd
jeeebz has quit [Ping timeout: 248 seconds]
erhankur has joined #openocd
erhankur has quit [Client Quit]
<Haohmaru>
any innocent command to just quickly confirm that openocd+debugger+target is working?
<Haohmaru>
like, to read the target's ID or something
<PaulFertser>
Haohmaru: just run it with adapter and target config.
<Haohmaru>
is there a list of the possible target .cfg files, i can't seem to remember the name of the file
<Haohmaru>
nor can i find such a list
gnom has quit [Ping timeout: 256 seconds]
gnom has joined #openocd
<PaulFertser>
Haohmaru: just list all files in target/ directory
<Haohmaru>
right.. who knows where that is
<Haohmaru>
oh, synaptic should know
<Haohmaru>
yey, found it
<Haohmaru>
/usr/share/openocd/scripts/
<Haohmaru>
so.. this ends up leaving openocd waiting and listening for gdb connections
<karlp>
then it's working.
<Haohmaru>
other than that, i see "Error: atsame5.cpu -- clearing lockup after double fault" "Polling target atsame5.cpu failed, trying to reexamine"
<Haohmaru>
should i be worried?
<PaulFertser>
You should start doing what you wanted this setup for ;)
<Haohmaru>
rule the world, one led-blink at a time
<Haohmaru>
oh, the debugger is blinking nervously
<Haohmaru>
okay, no blinking, but my debug usart printed its intro message at the right baudrate <success.jpg>
<PaulFertser>
Yay
<Haohmaru>
huh, well, surely i don't have yet any real big "program" .. i got a nearly empty main.cpp with some pin init and usart and an empty main loop, but stepping thru the init code is *fast*
<Haohmaru>
i mean.. it feels "normal" as if i'm debugging a normal program on the computer
<Haohmaru>
not like what i had @home
<Haohmaru>
same debugger, same OS, same IDE, the commands and settings might not be exactly idental
<Haohmaru>
oh well, this here is on a fancier CPU intel core i5-sumfinsumfin
<Haohmaru>
i'm on a core2quad at home
<Haohmaru>
could this explain it?
<Haohmaru>
or maybe my config at home is dumb/sub-optimal
<Haohmaru>
or <both.gif>
<Haohmaru>
my LED is unable to blink at 8.333MHz
<Haohmaru>
should've added some delay_ms there
<karlp>
xTaskDelayUntil...
<Haohmaru>
but could the debugging "slowness" be due to the CPU?
<Haohmaru>
core2quad vs core i5
<karlp>
doubt it, I've never see the sort of slowness you were reporting in the past
<karlp>
for me, in 99.99% of cases, stepping and shit on an embedded target with stlink/jlink is ~same as local
<Haohmaru>
like, you press "Step into" and it takes like up to a second usually before it gets the info about which line to go to
<Haohmaru>
yeah, right now here it's "normal" .. tho, i got almost nothing in the program, there's init code from atmel which i'm stepping thru and it's "fast" yet same debugger (zl33prg, cmsis-dap)
<Haohmaru>
same kind of long USB cable like at home
<Haohmaru>
my SWD cable is even longer here, like maybe 30cm (i used an ethernet cable because i needed 8 signals)
<PaulFertser>
Haohmaru: btw, how did you arrive at that link?
<Haohmaru>
was websearching for other things i think
merethan has joined #openocd
<PaulFertser>
Haohmaru: "you will often see a line reporting" "You can pass that information to GDB with these commands:" _can_, not _must_ or even should.
<Haohmaru>
maybe when i was searching for how to get a list of target configs, then i must've gone to the #contents and looked at other interesting things
<Haohmaru>
yeah, i know, but will anything "better" happen if i do it?
<karlp>
is a "non xml memory map" setup really supported?
<PaulFertser>
Haohmaru: hardware doesn't become better, no.
<Haohmaru>
okay
<PaulFertser>
Haohmaru: you should normally be using the official manual that you install along with the OpenOCD binary.
<PaulFertser>
karlp: I think yes, without memory map it should still work.
<Haohmaru>
PaulFertser this is openocd from debian11
<PaulFertser>
Haohmaru: so you the manual you have there on Debian.
<karlp>
PaulFertser: wel, that particular line is still in the 0.11 release html as I linked.
<PaulFertser>
Haohmaru: "info openocd" or any other way you prefer to view Info manuals.
<karlp>
it seems very unnecessary for most people.
<PaulFertser>
karlp: yes, I do not see it being wrong though.
<Haohmaru>
yeah but i was websearching about certain problems, not specifically trying to find solutions in the openocd manual
<Haohmaru>
also, when i websearch, i don't always click the first result ;P~
<Haohmaru>
nor the second one
erhankur has joined #openocd
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
jancoow has joined #openocd
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
Hawk777 has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
akaWolf has quit [Ping timeout: 260 seconds]
zjason` is now known as zjason
akaWolf has joined #openocd
emeb has joined #openocd
<merethan>
Checking I got my mind around things right: OpenOCD acts as a GDB server, my IDE (Code::Blacks in my case) is to be a client. Right?
<bencoh>
your IDE will probably run gdb in the background, and that gdb will act as a client
<bencoh>
but you're about right, yeah
<merethan>
I rarely used a debugger. Most often my code has sufficient error reporting. This time however, things just not run at all on a new platform.
<Haohmaru>
merethan Code::Blocks normally runs gdb, it knows how to do it
<Haohmaru>
here however, you wanna tell C::B to make gdb connect to a server instead of directly fiddling with the "program"
<merethan>
Alrighty, on to figuring out making it talk to OpenOCD.
<Haohmaru>
this server is openocd
<Haohmaru>
merethan i just did all of that
<merethan>
ctrl-c :P
<merethan>
How?
<Haohmaru>
create a new debugger config, because you probably don't want the "normal" gdb
<Haohmaru>
in my case it's gdb-multiarch (on debian)
<Haohmaru>
call this config "gdb-multiarch" or "openocd" so you know it
<merethan>
Ah by default it points to /usr/bin/gdb
<Haohmaru>
exactly, which in my case won't work, that's the normal gdb for.. debugging normal linux-ish apps
<merethan>
So the above binary only does things in the PC memory?
<karlp>
(depends, on fedora, "gdb" is multi arch and happily debugs arm...
<karlp>
(but.... it doesn't debug riscv, I need a riscv gdb for that ;)
<Haohmaru>
gdb can debug a program directly, or remotely
<karlp>
you can't go wrong ifyou just tell it it needs "arm-none-eabi-gdb"
<Haohmaru>
if you're writing a hello-world CLI app, you can debug it directly.. because that's easiest, BUT you could also debug it remotely
<karlp>
(going out on a limb that you are targetting cortex-m, but you haven't acytually said)
<Haohmaru>
yeah, actually, he didn't mention
<merethan>
Strangely the debian package does not have arm-none-eabi-gdb, karlp
<Haohmaru>
it doesn't
<Haohmaru>
install gdb-multiarch
<merethan>
Some package depends on it it seems; already have it
<karlp>
I mean the binary "arm-none-eabi-gdb"
<karlp>
I don't care or have any way of knowing how you get it.
<karlp>
might be from arm downloads directly, might be from your distro vendor...
<merethan>
There's none in Debian (by which I mean the filename, not only package names)
<Haohmaru>
then.. in project properties -> debugger, choose a target (release/debug/whatever) and configure the thing.. IP: localhost, port: 3333, "connect with extended-remote"
<Haohmaru>
in the additional GDB commands, you wanna put some commands to.. openocd
<Haohmaru>
at the end, from the Debug menu, Active debuggers, choose the "openocd" config you made earlier
<Haohmaru>
i could give you more detailed info when i get @home
<merethan>
Think I'll figure it out from here. Tnx!
<merethan>
Have an idea where to look and what to search for now.
<Haohmaru>
"do not execute debugee" is another option you wanna check
<Haohmaru>
for the gdb-multiarch config
Haohmaru has quit []
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<merethan>
Mm not much docs (forum posts mainly), and errors so far not very descriptive.
<karlp>
soooo what's your actual problem?
<merethan>
"The target is only running pre/post build step commands, can't debug such a target"
<merethan>
I wrote the whole thing up in CMake, not know how much the translation to C::B project hurts ability to run debugger.
<merethan>
It is supposed to not require much: I have a binary which I flashed using OpenOCD, the OpenOCD gdb server runs: Load .elf and connect to gdb server.
<merethan>
Not much to it ya think?
<karlp>
so.. what hve you had working before? do you know that openocd + gdb on the cli and your hardware are all working? are you just trying to get code::blocks working? or is this completely new to you?
<merethan>
I previously did flashing from cli
<merethan>
So that all works and OpenOCD acts as a gdb server for me.
<merethan>
All I need is for C::B to talk to it and tell me in what part of memory the chip got stuck.
<merethan>
Part of memory translated to what function is there, if possible
<merethan>
The thing just does squat right now and I not know why.
<karlp>
ok, no idea how to drive code::blocks, but just plain gdb will do that...
<merethan>
Well if I spend the time figuring out C::B now, I can use its functionality later on multiple times too ;)
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<merethan>
..and if I get it right in some portable manner, my colleagues may be persuaded to drop Arduino at some point.
<merethan>
Which, ultimately, is the goal of me doing all stuff in CMake: Have some sort of CI/CD with tests going.
<karlp>
I've heard of people using code blocks for embedded, so I don't believe it should be complicated :)
<karlp>
it should be just what Haomaruh was talking about, you're just telling it which gdb to use with which command lines...
<merethan>
Nah me neither. But there's little docs on it or my searching skills suck.
<karlp>
so how did you pick codeblcoks if it sucks so much? :)
<merethan>
I just checked the debian repo's, crossed out all the large projects like vscode, Eclipse, Netbeans and settled on Code::Blocks :P
<merethan>
First time using it for me.
<merethan>
So far does all the things I want.
<karlp>
except, like, you know, the thing you want it to.... :)
<karlp>
you crossed out the big ones because?
<merethan>
Memusage.
<merethan>
And there's some sense of adventure involved too.
<karlp>
ok, I'm going to leave you to it then :) we're clearly on different wavelengths :)
<karlp>
it soundsd like openocd's doing it's part at least :)
<merethan>
Yes so far does great!
<merethan>
Reason I went with Code::Block is similar to why I went with OpenOCD: Just try some else for the experience. Could also have gone with STM's IDE and a Segger.
<bencoh>
cmake for embedded work is an interesting choice
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<merethan>
So far works like a charm.
<merethan>
I use it to compile Arduino projects, which at some point are to no longer be Arduino projects. Got it all going for 2 out of 3 platforms. Need the debugger now for this final platform because I not know why it gets stuck.
<merethan>
Might have screwed up some startup code of oscillator settings not right... So much to go wrong with this, need to narrow down my area.
<merethan>
Oops getting late. Need to ride my bicycle home for 90 minutes, and have dinner.
<merethan>
Due to docs on remote debugging being sparse for Code::Blocks (or my web searvh skills being very sucky), think I need Haohmaru some more tomorrow.
<merethan>
Tnx for help!!
merethan has quit [Quit: Leaving]
nerozero has quit [Ping timeout: 250 seconds]
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
<antto>
oh, hm.. here (on this setup), i have arguments "tar remote" to gdb
<antto>
i don't have the "set remotetimeout 10" and the "monitor sleep" isn't 100 but 1000 here
<antto>
hm, i also updated the firmware of the debugger to the newest one (from 2019, huh) but i think i should have done this here too (don't remember)
<antto>
well, when C::B runs gdb here, for some reason, it opens an additional terminal (which stays empty), this didn't happen at $job
<PaulFertser>
antto: better use "extended-remote" so that "start" and "run" would be available.
<PaulFertser>
antto: I do not think you need to change remotetimeout from default.
<antto>
extended-remote is mentioned in my .html
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<antto>
okay, i had configured the project to be a "console app" that's why C::B was opening that terminal window
<antto>
it seems the stepping thru is "better" now, on some steps it takes longer, including several minutes
<antto>
i suspect maybe the generated asm is perhaps chaotic so "the next line" might not always make sense
<karlp>
if that's whats happening, you should be able to see hta that happening on the openocd command line, at least at higher debug levels.
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
<karlp>
that will happen whenever it can't use breakpoitns to move intelligently to the "next" line
<antto>
i press Next and it teleports me to the destructor (or was it constructor) of a RAII helper object
<antto>
yeah, so, there's almost no function calls left in the asm i guess.. after optimizations
<antto>
when this disassembly window is open, the IDE seems to be $obtaining the instructions via the debugger, so it takes a long time to fill that window
<karlp>
it might also be dumb about how it's doing it too,
<antto>
when i step, it re-reads the asm from the debugger again
<antto>
possibly dumb, or something isn't configured properly
<antto>
could asm instructions magically change during stepping? ;P~
<antto>
can stuff with delay_ms() cause glitches during stepping?
<antto>
well, it's faster now, it seems that when you have fancy debug windows open (watch list with a lot of variables in it) stepping is slow-ish
<antto>
but it occasionally takes like over a minute on some steps
<antto>
the program here has a bit more things going on, there's multiple usarts, with interrupts, and some other crap
<karlp>
it's also kinda risky, lots of those registers it might be trying to show you have things that change when you read them...
<antto>
in the meantime, the openocd window prints stuff like "Error: Failed to read memory at 0xfffff000"
<karlp>
yeah, soudns like c:b is asking for all sorts of de-referencing that is... perhaps shouldn't be?
<antto>
C::B is highly configurable, which is both good and bad
<antto>
so it might be my fault ;P~
<karlp>
gh, this other fork's efm32-s2 patches can flash, but not via gdb. same weird halting issue.
<karlp>
but at least it flashes,
wolfshappen has quit [Quit: later]
wolfshappen has joined #openocd
<Hawk777>
> could asm instructions magically change during stepping?
<Hawk777>
Sure, self-modifying code? Code that loads other code from some kind of storage? The paranoia kind of makes sense.
v0|d has joined #openocd
sbach has quit [Read error: Connection reset by peer]