crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
Hawk777 has quit [Quit: Leaving.]
nerozero has joined #openocd
Haohmaru has joined #openocd
merethan has joined #openocd
<merethan>
Haohmaru, yesterday I was confident I could figure out gdb & Code::Blocks with the hints you gave me, but the docs are really sparse or my web search skills suck. You mind spilling some more beans on what you've figured out?
<Haohmaru>
you can ignore the irrelevant things from there
JakeSays_ has joined #openocd
JakeSays has quit [Ping timeout: 256 seconds]
<PaulFertser>
merethan: what issue do you have exactly? Do you have gdb working nicely and just integration with C::B plays up?
<Haohmaru>
with this setup, the .elf is flashed to the MCU every time you start debugging, this perhaps isn't too great, always..
<Haohmaru>
i'd guess he doesn't wanna use gdb CLI at all
<PaulFertser>
It's important to first get simple things working.
<Haohmaru>
for the unfamiliar, gdb CLI isn't exactly simple IMO
<Haohmaru>
but sure
<PaulFertser>
It's simple in configuration.
<PaulFertser>
Because adding an IDE to the mix is more configuration, not less.
<Haohmaru>
true
<merethan>
Yes the debugger works PaulFertser. OpenOCD acts as gdb server.
Steffanx- has joined #openocd
<PaulFertser>
merethan: so what doesn't work?
<merethan>
When I hit debug on Code::Blocks I think it wants to perform a flash operation, which I not have defined (I think), then gives up with "The target is only running pre/post build step commands, can't debug such a target"
<merethan>
Compilation all works and I can do the debugging from CLI with OpenOCD.
<merethan>
*flashing, excuse me
<merethan>
I can do flashing from CLI.
<Haohmaru>
is this after you applied the settings from my page?
<PaulFertser>
What commands did you configure to be run in "pre/post build" steps?
<merethan>
Still going trough them Haohmaru
<Haohmaru>
ah, k then
<merethan>
I'm still figuring out what those phrases mean PaulFertser. I wrote up my entire project in CMake and have it translated to Makefiles & Code::Blocks project.
<Haohmaru>
ah, so you're not actually building with C::B's build system
<merethan>
Well I can hit build in C::B and it works.
<Haohmaru>
yes, but probably using an externally provided makefile
<merethan>
Ineed.
<merethan>
*Indeed
* merethan
keyboard is sketchy
<merethan>
10yo laptop
<Haohmaru>
my "tutorial" is about setting up a "normal" C::B project, which builds using the IDE's own build system
<Haohmaru>
but this won't really change the openocd-related instructions
<merethan>
Probably shouldn't
<merethan>
I worry about C::B refusing to begin executing them
<merethan>
"The target is only running pre/post build step commands, can't debug such a target"
<merethan>
Just connect to gdb and load the memory map, damnit :P
<Haohmaru>
so the cbp file was generated by cmake?
<merethan>
Yes
<Haohmaru>
naughty
<merethan>
So far worked just fine.
<Haohmaru>
sure.. but who knows how it's configured
<merethan>
Exactly my problem/fear
<Haohmaru>
check a few things: the project must have at least one target (but may have several)
<merethan>
Ctrl+F9 (build) works great
<Haohmaru>
go to Project Properties, then check each target's "type" .. for bare-metal it should be "Native"
<Haohmaru>
that's in the Build Targets tab
diddly has quit [Quit: leaving]
diddly has joined #openocd
<merethan>
They were set console app Haohmaru, even though I could never run them locally as they are ARM binaries.
<merethan>
But native now
<Haohmaru>
right, how many targets are there?
<Haohmaru>
(i'd guess just one)
<merethan>
A bunch, generated by CMake: all, rebuild, and each part of the project individually.
<merethan>
And the main build result: An .elf file.
<Haohmaru>
okay, so i guess you care about the "all" target, is that what's selected in the toolbar near the Build button?
<merethan>
That's the selected target yes
<merethan>
Selected debugger is gdb-multiarch
<Haohmaru>
k
<merethan>
which has "Do not run debuggee"
Bertl_zZ is now known as Bertl
<Haohmaru>
so in the "Project properties -> debugger" where you set the IP:Port and openocd commands, you'd wanna select the "all" target
<Haohmaru>
either that or the project main target
<merethan>
Exactly the way it is
<Haohmaru>
so, does it work now?
<merethan>
No popup with the message "The target is only running pre/post build step commands, can't debug such a target"
<Haohmaru>
ah
<Haohmaru>
so C::B is telling you "i see you have configured your project to be built using some external makefile, and some pre/post build step commands, so i won't allow you to use the debugger"
<Haohmaru>
huh
<Haohmaru>
lemme see if i can find some explanation about why this could be not allowed
<merethan>
I haven't grepped C::B source yet
<merethan>
Now I know I have the same setup as you have (save for the CMake-generating-cbp thing), which did work for you, the logical next step is to look into C::B.
<merethan>
All about shrinking the problem domain.
<Haohmaru>
i am NOT using external makefile (i could have, but my tutorial explains precisely how to take the interesting information out of that makefile and put it into C::B's project so you can continue "normally" in the IDE, add more files, blahblah)
<Haohmaru>
with the external makefile, C::B practically has no clue what exactly are you building
<Haohmaru>
so a lot of its features are bypassed
<Haohmaru>
i can't seem to find anything about the reasoning, but i did find at least one person complaining (on some cmake mailing list) that the generated cbp projects from cmake are not "runnable" and "debuggable" in C::B
<merethan>
Good find anyway. Appears nobody worked on this feature since.
<merethan>
Guess that makes my easiest avenue to learn the gdb CLI/TUI. And CMake & C::B being open source projects, responsibility for fixing it being mine.
<Haohmaru>
cmake could have generated a "better" cbp file tbh
<Haohmaru>
but maybe no one complained
<merethan>
Well it is bit of a niche IE.
<merethan>
*IDE
<Haohmaru>
i think i remember that some tool related to cmake was using .cbp file as its main format to figure out project build settings because other formats were probably uglier
<Haohmaru>
uh, QtCreator it seems
<merethan>
Could be. Makes sense to reuse formats rather than inventing yet another.
<Haohmaru>
meaning that it prefers to deal with .cbp than to deal with cmake's own files
<merethan>
QtCreator originally used qmake.
<merethan>
Their own homegrown build mechanism
<Haohmaru>
perhaps someone needs to submit a bug report about the .cbp generator of cmake
<merethan>
Or just fix it :P
<merethan>
Think this issue is on my plate given I am the one in need for it.
<Haohmaru>
well, i was also thinking about maybe, perhaps, using an external build system for this project..
<merethan>
But I'll need to have a clone of myself due to there only being 24 hours in a day :/
<Haohmaru>
i asked around about cmake but the replies i got weren't sounding very nice
<merethan>
on IRC?
<Haohmaru>
my question was sorta like "so cmake is supposedly wonderful for ready-made projects where you just $obtain some archive of source code, unpack it, then you merely run some cmake command and the magic happens"
<Haohmaru>
"but how is the actual developing side of things? do you have to edit cmake files when you wanna add another .cpp/.h file?"
<merethan>
Yes, but sometimes it won't, so maybe we need a higher-level language which makes CMake files to fix that ;)
<Haohmaru>
i don't remember the exact answers but it must've not sounded very nice and i went for C::B again
<merethan>
Yes I just edit my CMake files Haohmaru. C::B is only my editor.
<Haohmaru>
right
<merethan>
Bulding & flashing I just do on my CLI.
<Haohmaru>
this workflow sounds good tbh
<merethan>
C::B does do highlighting on CmakeLists.txt reasonably well too.
<merethan>
CMakeLists.txt
<merethan>
Case-sensitive
<Haohmaru>
1. you learn cmake (ah, i'd love to skip that but, okay), 2. you mainly use cmake to control the project settings/build settings, 3. you re-generate the .cbp file from cmake when you change stuff, the IDE will notice and ask to reload the project.. all good
<merethan>
Exactly
<Haohmaru>
then you get the "pro-ness" of having cmake for your project, and the convenience of writing the code with the IDE
<Haohmaru>
except, cmake's .cbp files are dumbified
<merethan>
Yeah
<merethan>
But CMake is nicely scriptable, which I want as I ultimately go for a CI/CD. And sorta portable between IDE's my colleagues like.
<merethan>
vscode opens CMakeLists.txt natively.
<merethan>
Eclipse & QtCreator sorta do too.
<merethan>
It sure ain't perfect, but as a tool it works reasonably well. This thing we just deduced into being semi-impossible at this moment (until we go patch CMake & cbp), is the first major drawback I run into.
* merethan
lunch
<merethan>
Guess I'll be learning gdb cli/TUI after lunch :P
<Haohmaru>
i've done gdb cli a bit.. it's not too fun
<Haohmaru>
but it's usable
<Haohmaru>
obviously if you learn the cli you'll probably be faster than a GUI click-clackz0r like me
<Haohmaru>
i have mplabx that's afaik rebranded netbeans
<Haohmaru>
hm, the other possible approach would be if C::B could generate a cmake file
<Haohmaru>
but maybe that's less useful
<Haohmaru>
(actually would be more useful for me, since then i would be able to not have to learn cmake)
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
<Haohmaru>
merethan which version of C::B btw?
<Haohmaru>
i just made an empty project, configured it to use an external makefile, i don't even have a makefile nor any source/header files, pressed Debug and it tries to run gdb
<Haohmaru>
oh, hm, is "all" maybe a virtual target?
<merethan>
Is that C::B terminology or something makefiles do?
<Haohmaru>
C::B
<Haohmaru>
but nah, it can't be a virtual target
<Haohmaru>
could you pastebin the .cbp file?
<Haohmaru>
or give screenshots of Project Properties -> build targets -> "all"
<merethan>
My Code::Blocks version is 20.03; the version in Debian 11 Bullseye
<Haohmaru>
try a different target, one which seems adequate and contains the source/header files of interest
<Haohmaru>
select that target as active (from the toolbar) and try debug with that
<Haohmaru>
you should then put the relevant debugger/openocd settings to that target
<Haohmaru>
so cmake's cbp isn't as bad as i thought
<merethan>
Well ow it does something
<merethan>
now
<Haohmaru>
tho, why it uses absolute filepaths so much
<merethan>
Because CMake does that.
<Haohmaru>
eww
<merethan>
No all the paths are relative in CMake files
<merethan>
But when they go into variables they are made absolute so you can reuse them variables in other CMakeLists.txt files, which have different working directories.
<merethan>
This project you now glance at is 4 CMakeLists.txt's
<Haohmaru>
so with a more suitable target, it doesn't refuse to even run a debugger?
<merethan>
It does do something now. I get a console window, presumably for running the "console application" it thinks this project is.
<Haohmaru>
right, change that target type to "Native"
<Haohmaru>
debugging should work, it's a matter of setting up the openocd commands and settings for that target now
<merethan>
Seems to do something
<merethan>
It should not need any openocd commands I think, as I manually run it from cli
<Haohmaru>
nonono
<merethan>
It is already up and running, acting as gdb server.
<Haohmaru>
the "mon reset halt" type of commands
<Haohmaru>
the IDE sends those thru gdb to openocd (afaik)
<merethan>
I'll go read your page again
<Haohmaru>
also, the IP:Port and the checkbox
<Haohmaru>
"extended-remote"
<merethan>
Yes got those
<Haohmaru>
for *that* target
<Haohmaru>
(each target can have completely different settings)
<Haohmaru>
unfortunately, those settings will go in the trash when you re-generate the .cbp
<Haohmaru>
but perhaps, you could maybe use some script or little program to "decorate" the freshly-generated .cbp file after cmake
<Haohmaru>
.cbp is actually xml
<merethan>
Yes I noticed.
<Haohmaru>
when you get debugging working, you might wanna "Save project" and then copy the modified .cbp under a different name
<merethan>
It does connect to the gdb server now
<merethan>
But I can't break execution
<Haohmaru>
is the break button not clickable?
<Haohmaru>
* pause button
<Haohmaru>
a possibly useful option is "Settings -> Debugger -> Common: [X] Full debug log
<Haohmaru>
this will cause a more verbous output in the "debugger" log window
<Haohmaru>
but you might wanna turn that off after the problems are solved, because it'll be very noisy
<merethan>
I can press pause but it not do much
<merethan>
Memdump however works
<Haohmaru>
see the debugger log for anything interesting
<Haohmaru>
also, you might wanna throw an eyeball at the terminal where you got openocd running
<Haohmaru>
sometimes sh*t happens
<merethan>
So far so good. Can see it do stuff I requested in CB
<Haohmaru>
kewl
<Haohmaru>
save the project, also, i think C::B even to this day only saves its global settings on exit (that's global compiler/debugger options, syntax highlight, basically everything in settings) so you might wanna also close C::B and reopen it
<Haohmaru>
;P~
<Haohmaru>
(i live in a country where power outtages are sometimes too frequent)
<merethan>
Now things are sort-of figured out, the number of changes turns out not too huge
<merethan>
My PC has a battery Haohmaru ;)
<Haohmaru>
that's cheating
<merethan>
10yo laptop, but still has life in it
<Haohmaru>
still, C::B sometimes can crash
* merethan
forgot to enable debugging in compiler
<Haohmaru>
so i'd think, if you could write a little script, you'd need to take the cmake .cbp file and, only for the interesting target, change the "Type" to Native (that seems to be an integer in the file), and then add the debugger-related things, again, only for that target
<merethan>
Probably. Because doing it over and over manually will get old very soon.
<Haohmaru>
you could also make that script output the modified .cbp under a different name
<merethan>
So far it won't break the execution, but I can read arbitrary memory.
<Haohmaru>
huh
<merethan>
It tries to send SIGINT, which appears to me that somehow it still does stuff related to a local running binary
<Haohmaru>
try this: stop debugging, put a breakpoint somewhere where you know it's gonna walk by, and then do Debug/Continue
<merethan>
Well that's the problem: The chip freezes and does not reach main()
<Haohmaru>
o_O
<merethan>
There's something going on with interrupts or reset vector or things not being in the right place in mem.
<merethan>
Hence I need a debugger to figure out what the heck is wrong
<merethan>
Unless SIGINT is also in gdb lingo, there's still some wrong with what CB does.
<PaulFertser>
merethan: I suggest you do this in plain gdb: "mon reset halt", then you can use "si" and you'll be sitting at the reset vector.
<PaulFertser>
merethan: then you can use the IDE to step etc.
<PaulFertser>
merethan: does your IDE allow to send arbitrary gdb commands?
<merethan>
Probably, but I have not figured out how yet
<merethan>
I can also open telnet to OpenOCD
<PaulFertser>
merethan: usually if you do not get to main() it means either you're compiling for the wrong MCU or you have stack pointer set wrong (e.g. when assuming it has more memory than available).
<merethan>
There's also things like startup_ARMCM0plus.S that I might have gotten wrong.
<Haohmaru>
PaulFertser when you pause, there's a commandline editbox in the debugger log window for typing commands
<Haohmaru>
..in C::B
<Haohmaru>
it's grayed out when the target is running tho
<PaulFertser>
Haohmaru: then it's the right place, merethan can use that and then continue stepping in C::B
<PaulFertser>
Or just add "mon reset halt" "si" command to the place where launch gdb steps are configured.
<Haohmaru>
oh, crap
<Haohmaru>
there.s .S source files involved
<Haohmaru>
no idea how debugging goes with those
<merethan>
It mainly contains stubs for interrupt vectors and the likes
<merethan>
Just so the linker has some stuff to put in places the linker script wants something.
<merethan>
But also code for the reset vector
<Haohmaru>
i should figure out what those commands do and annotate them in the document
<Haohmaru>
because i found them $somewhere and just copy/pasted them and no clue wtf's going on exactly
<merethan>
..and there's system_stm32l082xx.c, which has stuff for manipulating the oscillator and many more things, but functionality in there is also partially programmed into the Arduino code I am to use, so getting that right is a linker minefield as well.
<Haohmaru>
"si" smells like short-version of GDB's "step into"
<Haohmaru>
but i was talking about the "mon reset halt" stuff, "load xyz" "file xyz"
<merethan>
Step into a mine :P
<merethan>
si:
<merethan>
> si
<merethan>
halted: PC: 0xd0002b00
<merethan>
In ?? () ()
<merethan>
0xd0002b00 in ?? ()
<merethan>
Which normally would display a function name?
<Haohmaru>
so the program doesn't know where its at
<Haohmaru>
do you have debug symbols btw
<merethan>
-g at compile
<Haohmaru>
is your .elf build using..
<Haohmaru>
i've seen -g3 recommended more
<merethan>
Will try
<Haohmaru>
it has some extra debug info or something
<Haohmaru>
also, very important
Steffanx- has quit [Quit: Connection closed for inactivity]
<Haohmaru>
besides setting "Native", you'd wanna make sure the output filename matches the real file that cmake builds (the .elf)
<bencoh>
a bit late, but if you plan on learning gdb tui, you'll probably want to check cgdb first
<Haohmaru>
since C::B (i think) tosses that file as an argument to gdb-multiarch
<merethan>
Just installed bencoh ;)
<merethan>
Will try next
<bencoh>
:)
<merethan>
Same result Haohmaru:
<merethan>
halted: PC: 0xd0002b00
<merethan>
0xd0002b00 in ?? ()
<merethan>
Needs a .map file? Same info should now also be in .elf with -g3
<Haohmaru>
i think gdb (the gdb which the IDE, or you (via CLI) use) should be supplied with the debug symbols
<Haohmaru>
the gdb-server (openocd plays this role in our case) probably doesn't need it
<Haohmaru>
the IDE invokes gdb, it would supply the .elf (the debug symbols are in it)
<Haohmaru>
so if the filename doesn't match, or if it's not built with debug symbols - it won't work
<merethan>
I made sure output filename matches
<merethan>
No change
tsal has quit [Ping timeout: 248 seconds]
<Haohmaru>
GDB can still debug, but you won't be able to know where you are within the source code
<Haohmaru>
you'll probably know some position in the program (address offset) and what instructions are there but.. who even understands machine instructions ;P~
<Haohmaru>
so uhm, let me ask
<Haohmaru>
at the moment, your program should be working? or you have a bug already?
<merethan>
The chip just freezes for all I know
<Haohmaru>
because it's easiest to verify the debugger operation with something like a hello-world or led-blinker which "works"
<merethan>
I can go make that
<Haohmaru>
so, you don't have a working firmware
<Haohmaru>
so maybe the debugging/IDE/openocd setup might actually be "okay"
<merethan>
Right now all options are open.
<Haohmaru>
well, the general setup is at least 95% working (ide-gdb-openocd) IMO
<merethan>
Quite an accomplishment so far yes :)
<Haohmaru>
add "debugger device" to that list too
<merethan>
I really appreciate the help of you all, Haohmaru in particular this time.
<Haohmaru>
you could enable the "Full debug log" for now, perhaps
<Haohmaru>
there may be some extra clues in it
<Haohmaru>
also, cmake isn't like calling "strip" or some such on the .elf, is it?
<Haohmaru>
"strip (debugging) symbols from executable binary"
<Haohmaru>
you'd want that when you make ClosedSourceProgram.exe but not in this case
<merethan>
Oh wait I have that in link options
<merethan>
Oops
<Haohmaru>
>:)
<Haohmaru>
naughty
<merethan>
xD
<PaulFertser>
It makes no sense to not use -ggdb3 always, the debugging info is only in ELF, it's not adding any bloat to the binary.
<merethan>
Spend all the time compiling with -g3, then dump it all next step
<Haohmaru>
PaulFertser cmake probably isn't written with bare-metal in mind
<Haohmaru>
neither is C::B tho
<Haohmaru>
"strip" is also a good idea maybe when you wanna make the .exe smaller in size
<PaulFertser>
Haohmaru: it doesn't matter.
<merethan>
It's not geared towards it no, but should not be constrained from embedded either.
akaWolf has quit [Ping timeout: 248 seconds]
<PaulFertser>
Haohmaru: strip is useless for Cortex-M as you run binary there on the target, not full ELF.
akaWolf has joined #openocd
<Haohmaru>
merethan but default settings are often oriented towards the "main" usecase scenarios
<Haohmaru>
so that all those folks have less configuring to do
<merethan>
Nah this case I did put it there
<merethan>
But forgot about it
<Haohmaru>
while niche folks like bare-metal have potentially more default settings to fight with
<Haohmaru>
aww, so it wasn't default
<PaulFertser>
merethan: btw, what are the first 8 bytes of your binary? Should be a pointer to the end of RAM and reset vector address.
<PaulFertser>
merethan: and when you do "reset halt" OpenOCD prints "pc" register to console so you can verify.
<merethan>
Will do in a moment
<merethan>
No change Haohmaru :(
<Haohmaru>
huh
<Haohmaru>
the .elf should be bigger now, at least
<merethan>
I should now have debugging symbols using -ggdb3 and not stripping. I can try to independently verify they're there.
<Haohmaru>
another common fault is, you're watching one .elf, but building a different .elf ;P~
<merethan>
Uno momento
<merethan>
lol I know that mistake already, I watched carefully :P
<merethan>
Not it makes the mistake impossible, but I was aware.
<Haohmaru>
i do too, and yet i still do it from time to time
<merethan>
Oh lol there's a *clear* size difference, think I can safely conclude its all there :P
<Haohmaru>
yeah the .elf should be huge with the symbols
<PaulFertser>
merethan: check the first bytes of the binary, probably you're getting wrong reset vector there.
<merethan>
reset halt followed by si?
<Haohmaru>
PaulFertser that's the .bin, not the .elf, right?
<PaulFertser>
Haohmaru: please rephrase
<merethan>
My linker script puts Reset_Handler first, of which the first section is .isr_vector
<PaulFertser>
Haohmaru: yes, I'm asking merethan for the first 8 bytes of the binary, not elf.
<Haohmaru>
you meant the first bytes of the binary, not the .elf itself
<Haohmaru>
right
<merethan>
Working on it PaulFertser
<karlp>
bencoh: what does cgdb do that gdb --tui doesn't?
<karlp>
it looks like coloured source listings maybe?
<merethan>
PaulFertser: 48 05 4B 10 B5 83 42 03
<merethan>
In hex
<karlp>
shouldn't first 4 be "somewere in ram" ?
<karlp>
what part is this?
<bencoh>
karlp: mostly the friendlier source panel yeah
<merethan>
I dumped the binary from the .elf, read you the first 8 bytes with a hex editor
<merethan>
"Hey lets do a total rewrite!" wasn't sellable for financial reasons.
<Haohmaru>
add arduino.cc to the blacklist of domains in the DNS
<karlp>
I'm just saying, if you had a working build system earlier, that was workign, and you could flash and debug with gdb,
<karlp>
I guarantee it didn't have that mess in the first 8 bytes of the bin...
<karlp>
so either your "make" process has changed, yuo didn't drive some tools properly to check, or it never worked, and you were seeing old code still?
<Haohmaru>
at this point i can bet his debugging setup is probably 99.8% working
<merethan>
Arduino IDE is already out the window now I have my own build system in CMake. Will later become a Ci/CD too.
<Haohmaru>
now he has to get a sane firmware
<merethan>
Some minor detail is wrong.
<merethan>
I did this to two other platforms already, but for some reason the company wanted to use yet another chip.
<Haohmaru>
so many things need to be "just right" for a LED to blink
<Haohmaru>
chip shortage ;P~
<merethan>
No this was laziness.
<merethan>
Or maybe clueless too.
<merethan>
Already got this done on SAMD and nRF52, works great. But this Murata CMWX1ZZABZ (a STM32L082CZ) is a pain so far.
<Haohmaru>
huh, a rf module by murata, with an stm32 in it
<merethan>
Yes
<merethan>
Japan went nuts
<merethan>
:P
<Haohmaru>
i guess they are maybe showcasing some of their inductor stuff.. antenna?
<merethan>
OMG not Hitachi, NEC??
<merethan>
Renesas??
<merethan>
Some people got mad a STM was used, probably.
<PaulFertser>
merethan: so you can do "objdump -a -S your.elf" and see what exactly happens to be put in the section.
<merethan>
Working on it
HelloShitty has quit [Ping timeout: 272 seconds]
<karlp>
murata's been making bt and wifi modules for years with various silicon under the hood.
<merethan>
You were right PaulFertser: My __isr_vector was missing
<merethan>
Fuck. How come my linker script did not complain??
<karlp>
which means it either didn't work before either, oryou changed something :)
<karlp>
your linker script won't care if things aren't there, it just includes what it finds....
<merethan>
Ah yes, I was to bring you up to speed
<karlp>
yeah, don't worry about bringing me up to speed.
<karlp>
you sounds like you'r eon track again, and I really don't need more distractions :)
<merethan>
So, things never worked for this platform. The code is not mine. I am to make a horrible Arduino project work such it can become some kind of CI/CD.
<merethan>
And the chip froze. To figure out why, I went to get OpenOCD to work.
<merethan>
But now tnx to some hints by PaulFertser, the freezing answer is just in plain sight in the .elf
<PaulFertser>
merethan: yay :)
<merethan>
Not I gonna stop getting OpenOCD to work now I got this far.
<merethan>
Might as well get that going :P
<karlp>
so this:
<karlp>
17:03:00 merethan | I previously did flashing from cli
<karlp>
17:03:27 merethan | So that all works and OpenOCD acts as a gdb server for me.
<karlp>
was just... wrong?
<merethan>
No it worked
<merethan>
But the chip itself did not run anything
<karlp>
ohkay...
<karlp>
I thought you had it _working_ and were trying to get code blocks to work
<merethan>
Well that was part of the challenge yes
<karlp>
not "I "flashed" something, but I dont' even know if it works or not, because nothing runs anyway"
<karlp>
how would you have even know if flashing had worked?
<merethan>
Because I could dump memory
<karlp>
I kinda assumed that you had flashing and debug via gdb working form what you said...
<merethan>
And OpenOCD did say "verified" after write
<merethan>
Tnx to Haohmaru I got C::B to talk to gdb server in OpenOCD, but it not yet tells me what line is executing & stuff. Although I can query for a memdump in C::B.
<merethan>
Whoa it runs! Not I found the issue with OpenOCD, but it was hell of a leaning experience I can use later.
<merethan>
Love you all!
<merethan>
The internet is great!
<PaulFertser>
And OpenOCD in particular :)
<merethan>
jtag should be independent from the cpu, but the STM32 going into sleep state breaks it
<PaulFertser>
merethan: if it's deep sleep, probably. But breakpoints are still set so when it wakes up it'll stop on breakpoint and you get control.
<merethan>
Haohmaru, C::B now works too :D
<Haohmaru>
kewl
<merethan>
Sortof
<Haohmaru>
what's wrong?
<PaulFertser>
If you feel like writing a blog article, it can be posted on openocd.org .
<merethan>
It did show me where in the assembly it is situated on halt
<merethan>
But it won't continue on command
<merethan>
There's probably a few quircks I am yet to figure out and learn to use
<merethan>
No problemo PaulFertser, I like writing.
<Haohmaru>
it's easiest if you can get a working project, one which doesn't have a ton of things that can go wrong.. a LED blinker or something
<Haohmaru>
then you can try stepping thru it, pausing it, continuing, blahblah, changing something in the code, confirming it really changed.. etc..
<Haohmaru>
i meant a working firmware
<merethan>
Yes this thing is a LoRa device which goes into sleep very quickly.
<Haohmaru>
aww
<merethan>
I'll go forward by disabling all the fancy sleeping stuff and experiment from there
<merethan>
And probably try cgdb, ddd and xxgdb too, to get a sense of what they are
<PaulFertser>
merethan: in OpenOCD configs for stm32 I see it enables special flag in DBGMCU_CR to debug in sleep but it is not possible for the deepest sleep.
<PaulFertser>
merethan: you can also try gdb -tui , the integrated TUI.
<karlp>
skip ddd, it's like 30 years old and hasn't been updated.
<karlp>
gdb --tui completely supersedes it unless you really run cde or fvwm2 or something as your daily driver and think those are the pinnacle of UX design.
<merethan>
Alright
<merethan>
Nothing wrong with being over 30 ;)
<merethan>
Ouch, it hurts my eyes
<karlp>
I tried :)
<karlp>
but seriously, start with gdb/gdb tui, only use the others once you know what you want or what you're runnign into.
<merethan>
lol xxgdb has some trouble with UTF-8
<karlp>
yeah, like, gdb is well known and widely used,
<karlp>
these others are all very niche really...
<merethan>
gdb-multiarch -tui for me then
<cambrian_invader>
not a fan of tui personally, because it doesn't play well with terminal scrollback
<karlp>
I can see that :)
<cambrian_invader>
gdb configs which print out the registers on the command line are very convenient, because you can go back and examine the state of the processor