NishanthMenon changed the topic of #openocd to: this is the place to discuss all things OpenOCD | Logs: https://libera.irclog.whitequark.org/openocd/
cmcmanis has joined #openocd
thinkfat_ has joined #openocd
thinkfat has quit [Ping timeout: 272 seconds]
boru` has joined #openocd
boru has quit [Killed (NickServ (GHOST command used by boru`))]
boru` is now known as boru
Hawk777 has joined #openocd
tsal has quit [Ping timeout: 258 seconds]
tsal has joined #openocd
nerozero has joined #openocd
Haohmaru has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Hawk777 has quit [Quit: Leaving.]
tarekb has joined #openocd
nerozero has quit [Ping timeout: 272 seconds]
Guest49 has joined #openocd
<Guest49> Hi All, first time here, so point me at any beginner info if appropriate (I've looked for FAQ, but haven't spotted any). I use openOCD for ARM development/debugging. I'm certainly no master! I'm trying to get to grips with ETM/ETB configuration to help work out the cause of stack corruption. Can anyone point me at some tutorial docs, or give me
<Guest49> some example commands that they use?
<karlp> there's virtually zero built in support for modren cortex etm that I'm aware of.
crabbedhaloablut has quit [Remote host closed the connection]
<karlp> there's been some work refactoring tpiu support in master to make it easier to come in, but Id on't think any of the explicitly ETM stuff is in yet.
crabbedhaloablut has joined #openocd
<PaulFertser> Guest49: do you mean you're trying to see the execution trace? What hardware do you have for that?
<Guest49> Thanks karlp! I'm learning a lot as I go on this (and coming back to it after a month away!) Just reading up on what the TPIU is and how it relates to what I'm hoping to do (still not clear on all the acronyms!)
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
<Guest49> Hi PaulFertser, yep I want to collect the execution addresses in to a buffer, then inspect the buffer when stack corruption occurs to see what the history was. Looks like the' ETM' with an ETB can do something like that.
<PaulFertser> Guest49: is your target cortex-a or cortex-m?
<Guest49> (automatcially as opposed to adding logs to my code to an in-memory buffer)
<Guest49> the target is a cortex-m
<Guest49> I did find this, which is what makes me think openOCD has some support already - though you may know: http://www.openocd.org/doc/html/Architecture-and-Core-Commands.html
<PaulFertser> Guest49: I fixed some corruptions on Cortex-M before using watchpoints.
<PaulFertser> I just start the firmware, halt it somewhere near the corruption event, place the watchpoint on the to-be-corrupted area and let it run.
<Guest49> unfortunately this device goes to deep sleep, runs fine for days and then, something happens... I suspect some kind of ISR interleaving is messing things up.
<Guest49> i.e. this code runs through the area that corruption is happening in many times before the impact is seen. it is also entirely possible there is an uninitialised pointer and that's slowly destroying parts of RAM, and eventually hits the stack.
<PaulFertser> Guest49: what optimisation level is used when you build the firmware?
<Guest49> This is also not my code... I'm running mbed-os with some comms drivers in a slightly different to normal use-case.
<karlp> there's good support for SWO and also exception trace via ITM.
<karlp> not all cortex-m's even have ETM hardware.
<Guest49> RE optimisation: I'm not entirely sure tbh! I use the mbed-cli to compile and use it's default settings for optimisation.
<karlp> dwt exception tracing might be good for you, and using all the ITM channels to do some instrumentation can get you a long way too. ETM is a very big cannon
<PaulFertser> Guest49: http://essentialscrap.com/tips/arm_trace/ related
<Guest49> I'm currently using an st-link2 devices which has an SWO pin, but never used that before. I've heard from others that Seggers are much better at handling that (no first hand experience to comment) - do you know if I can use the SWO pin on st-link (otherwise I can search that avenue too).. Thanks for all the input!
<PaulFertser> Guest49: I suggest you enable -O3 and LTO and it'll get buggy as hell and you'll find many bugs in the code :)
<PaulFertser> And probably one of the fixed bugs would be the one you're looking for.
<Guest49> PaulFertser: Thanks for that suggestions!
<Guest49> @kar
<Guest49> @karlp: thanks for that too - more avenues to search down - appreciate the input!
<PaulFertser> Guest49: also, when you get stack corruption, did you try to halt the target and look at the backtrace?
<Guest49> @PaulFerster: Yep - (rant: the mbed default handler RESETS the chip, then halts it, destroying any chance of a backtrace! Grr!) I replaced it with a while(1); and checked the backtrace, but there's very little info before I could get before corruption.
<PaulFertser> Guest49: is it running a RTOS?
<Guest49> PaulFertser: Not in the current project (bare-metal profile)
<Guest49> PaulFertser: I could enable the RTOS if that is likely to add debug info?
<PaulFertser> Guest49: implement stack and heap control yourself: spray everything free with markers, run a periodic function to check how many stack is free, whether the unused RAM changed etc.
<Guest49> PaulFertser: I like the idea, but it sounds like I could easily mess things up worse in the process! It would be a new approach for me and I'm not sure what functions I would need to override... good to have the suggestion though, but I'm leaning towards it being a back-burner after ETM/ITM - unless you think it's pretty simple?
<PaulFertser> Guest49: I think getting ETM/ITM to do what you want it to do is much higher than watermarking free RAM areas.
<PaulFertser> And monitoring
<Guest49> PaulFertser: Thanks for the feedback... I guess I'd need to hook some standard C functions to allow monitoring. Is there any info you know of about what would need to be done and how to do it? (I guess I'll try the -O3 LTO enabling and see what happens first - that sounds the easiest so far!)
<PaulFertser> Guest49: it's the easiest way to first spend few days on fixing the build, and then it might reveal some nasty bugs right away, so the easiest way to spend the next week debugging :)
<PaulFertser> Guest49: just scan the free RAM and stack for your watermark, then print results to UART or something.
<PaulFertser> I'm afraid I have no easy way to explain it if you're not yet familiar with low-level programming.
<PaulFertser> And the issue as you describe it sounds to be a tricky one to solve. Unless you find a better reproduction way. Or some really experienced developer to do the job.
<Guest49> going back a bit to karlp's comment: The ITM/SWO route sounds interesting too - is this something you(anyone here) has done and can comment on the process? (specifically thinking that I should perhaps order another programming device if I need better hardware to avoid delivery lags)
<PaulFertser> Guest49: I've sent you the link regarding it already. Not for the faint of heart.
<Guest49> PaulFertser: Thanks! I have that in a new tab, but haven't begun reading yet...
cmcmanis has quit [Ping timeout: 252 seconds]
<Guest49> I reckon I'll take all the suggestions (thanks again) and re-read this a few times and investigate the possible options, then start wading through lots of information and data. I suspect I'll be back to ask a few more Q's as I'll get in a muddle, but really appreciate the input and quick feedback!
cmcmanis has joined #openocd
<PaulFertser> Guest49: good luck!
Guest49 has quit [Ping timeout: 246 seconds]
<karlp> I use ITM/SWO a lot, it's well supported.
<tarekb> hey PaulFertser:
<tarekb> I hope you are doing well, you and everyone here ;)
<tarekb> Paul, I'm having an issue in windows build regarding static and dynamic link of openocd
<tarekb> currently in github action, the link of openocd against hidapi, libusb and libftdi is dynamic, so dll are used
<tarekb> but when building the libfdti.dll it requires to be statically linked with libusb, and there I have no clue how to solve this
<tarekb> :'(
<tarekb> do you have some hints ?
<PaulFertser> tarekb: hey :) Have you seen the "new" website?
<PaulFertser> tarekb: the easiest way would be to disable libftdi as it's used only by old USB Blaster I only.
<PaulFertser> tarekb: why it requires to be statically linked with libusb anyway? Probably that can be fixed in libftdi?
Guest49 has joined #openocd
Guest76 has joined #openocd
Guest49 has quit [Quit: Client closed]
ntfreak has joined #openocd
<tarekb> PaulFertser: wow, a new pretty website powered Perlican, this reminds me of Jekyll, I appreciate the effort and the pretrry simple touch ;)
<tarekb> BTW, I have already mentioned that the old forum (hosted by sparkfun) is kind of obselete and not maintained,
<tarekb> IMO this should be removed from the website
<tarekb> and under Repository tab, I'd expect to see the well know ntfreak mirror
<PaulFertser> tarekb: there was no touch, it's the default theme with few minor CSS tweaks I have no idea about. Are you by any chance a CSS expert?
<PaulFertser> tarekb: ok, will remove the link to the forum.
<PaulFertser> tarekb: noted, it's indeed our official github mirror effectively.
Guest76 has quit [Quit: Client closed]
<tarekb> I know little things about CSS and HTML stuff, so I'm far from being expert on this
<tarekb> BTW, I love the new donation tab, it's for sure needed for matining the jenkins server ...
<PaulFertser> tarekb: ok, never mind then. Thank you for the review! It's in fully manual mode now, but I plan to automate it so that we could post by just pushing to Gerrit.
<PaulFertser> tarekb: the content is all copied from old wordpress, donation button was there too.
ntfreak has quit [Quit: ntfreak]
<PaulFertser> tarekb: and also the static site could be hosted anywhere, so far it's ok on SF.net I guess.
<tarekb> I haven't noticed it, that's on me ...
<tarekb> static is always better, no big maintenance effort, IMO that's should be fine and enough
<tarekb> regarding libftdi, I will try disabling it, (I have tried several methods, but it always require static link against libusb, which blocks users from trying different version of libusb
ntfreak has joined #openocd
<PaulFertser> tarekb: if other programs can use libusb as DLL then nothing should prevent libftdi from that too. Probably something odd in their CMake file but I'm not an expert, would need to experiment and read about it.
<tarekb> PaulFertser: I'd love to find time for it, I have tried only the obvious ideas and checked quicly the cmake files, but in vain
<tarekb> now I need to clean up STM32L5 and U5 support in this summer, then maybe I can do further investigations with libftdi
<tarekb> BTW, PaulFertser: do you remember the story of USB support in WSL2 that was proposed by an NVIDIA engineer
<tarekb> I have encoutered a solution in github, but I haven't tested it yet, here it is: if some peeps are interested in : https://github.com/jovton/USB-Storage-on-WSL2
<tarekb> that's one step forward for USB support
<PaulFertser> tarekb: looks essentially the same hack as USBIP
ntfreak has quit [Quit: ntfreak]
tarekb has quit [Quit: Leaving.]
Haohmaru has quit []
akaWolf has quit [Ping timeout: 258 seconds]
akaWolf has joined #openocd
<rapha> PaulFertser: and hello once more :) ... sooo, i'm trying to flash an stm32f103 via USB now, trying to get around any soldering. it's a "fysetc cheetah" board, v1.1b. they've set it up in an interesting way where there's no bootloader. instead the uC is supposed to go into programming mode after you send some commands called "rts", "-dtr" and "dtr" through the on-board ch341 to its uart (uart1, i think, fwiw)
<rapha> using a tool called "stm32flash". unfortunately that's not working. is there a way to figure out what _should_ be happening and then replicate that using openocd? (i've read that ppl have had success with the windows GUI tool they provide, but i don't have a Windows box)
<rapha> PaulFertser: the funny thing is, _after_ you send "rts", then you can call "stm32flash" with just the serial port as the sole argument, and it'll print out some info such as "Device ID : 0x0414 (STM32F10xxx High-density)" or how much RAM there is, which seems to clearly come from the uC, which is why i think neither the USB connection and the board are broken.
<karlp> that method uses the rom bootloader of the stm32, which (in this case) runs over serial, openocd isn't relevant to this, and can't "replicate" it any anyway
<karlp> if stm32flash is showing you the deviceid properly, then what _isn't_ working?
<karlp> because that soudns like it _is_
emeb has joined #openocd
<PaulFertser> rapha: what karlp says
<dreamcat4> hello again (after many months)... i have some small issue the solution have been forgetton now....
<dreamcat4> so when programming this STM32 over SWD, there is no NRST reset line connected to control the reset. i have to physically hold and release the reset button on the target device
<dreamcat4> however my openocd startup command... it does not want to wait
<dreamcat4> -c "reset_config srst_only connect_assert_srst"
<PaulFertser> dreamcat4: if you do not have srst connected then you shouldn't be mentioning it in the command.
<dreamcat4> ah sure man! sorry stupid me
<PaulFertser> dreamcat4: use -c "init; halt" instead. Press reset, start openocd, release reset (within one second of OpenOCD executing halt). You should see it halted. that way.
<rapha> karlp: so, 'stm32flash -i rts ; stm32flash /dev/ttyUSB0' shows some info. but then 'stm32flash -w fw.bin -v -i rts,-dtr,dtr /dev/ttyUSB0' only says "failed to init device". from your explanation i take it that perhaps the ROM bootloader on the F103 might be ... missing?
<PaulFertser> rapha: it can't be missing.
<dreamcat4> well that connects while the MCU is running
<PaulFertser> rapha: if you see "some info" then it means it's working. Just do "stm32flash -w fw.bin /dev/ttyUSB0" right after you run -i rts.
<karlp> ^^
<dreamcat4> but then i try to program (in PIO), when it says 'cannot reset target' or something
* rapha tries again
<PaulFertser> dreamcat4: what's PIO?
<dreamcat4> holding reset and 'init; halt' didn't wait for me to release the reset button, it exit
<karlp> or just drop the dtr shits
<dreamcat4> platformIO (for vscode)
<PaulFertser> dreamcat4: it waits for one second
<karlp> what is this "init; halt" ?
<karlp> sorry, mixing up dreamcat and rapha
<PaulFertser> karlp: hm, right, should be "init; reset halt" to connect under reset.
<karlp> they're same colour here :|
<rapha> oh :P
<PaulFertser> dreamcat4: try that
<dreamcat4> thanks man! will try now
<dreamcat4> didn't work, different error under -d4
<PaulFertser> dreamcat4: show pastebin
<dreamcat4> sure
<PaulFertser> dreamcat4: you were not holding reset button manually at the moment you started OpenOCD
<PaulFertser> dreamcat4: or the target wasn't connected to debug adapter.
<PaulFertser> dreamcat4: I recommend -d3 , -d4 is too verbose
<dreamcat4> ah... for some reason when this LCD display daughterboard is plugged into the main board... then it messes up the signal
<PaulFertser> dreamcat4: why can't you connect another wire to make it comfortable?
<dreamcat4> like interference from the lcd or something
<PaulFertser> Soldering a wire to that button shouldn't be hard...
<dreamcat4> when i unplug the LCD then it works
<dreamcat4> perhaps i should mention this to the maker, the guy who design it
<PaulFertser> Not adding reset signal to SWD connection for a target that is supposed to be using sleep modes doesn't sound too wise.
<dreamcat4> well he used the arduino IDE, and programmed over serial. with both boot0 and boot1 pin set low
<dreamcat4> and in the first rev1 board didn't do anything at all for SWD
<PaulFertser> You can do the same, SWD works with boot pins pulled low.
<dreamcat4> is it still only waiting for 1 second? can i make that a longer time?
<dreamcat4> because it's pretty hard to get the timing right in the vscode (it is laggy etc)
<dreamcat4> got a successful connection now with both boot pin set low. thanks you
<PaulFertser> dreamcat4: reset halt; wait_halt 5000;
<dreamcat4> thanks, that worked a lot better man
<PaulFertser> :)
<rapha> karlp: so, even a sequence such as `stm32flash -i rts,-dtr,dtr -w fw.bin /dev/ttyUSB0 -v ; stm32flash /dev/ttyUSB0 ; stm32flash -i rts,-dtr,dtr -w fw.bin /dev/ttyUSB0 -v ; stm32flash -i rts,-dtr,dtr -w fw.bin /dev/ttyUSB0 -v` only yields one error, one set of device id and other info, then two more errors. could this be a baud rate or interference problem of any kind?
* dreamcat4 plugs LCD module back in, to create more trouble
<karlp> all I can say is that if it's reading out the device id, youv'e got it successfully talking to the rom bootloader.
<karlp> beyond that, not my field....
<karlp> I suspect you might have incorrect assumptions about rts/dtr and what's connected where?
<PaulFertser> rapha: show full pastebin of "stm32flash -i rts -w fw.bin /dev/ttyUSB0"
<rapha> trying ... went back to the odroid in between. there, nothing is working at all. have to go back to the laptop.
<rapha> what ... the ... ?!?!
<rapha> PaulFertser!!! you're a microcontroller WHISPERER!
<rapha> why did that just upload the firmware? was it leaving out -dtr and dtr?
<rapha> or leaving out -v?
<PaulFertser> rapha: the former
<rapha> i see :-/
<rapha> thank you
* rapha feels a little crushed but otherwise a little more happy also
<rapha> so what does "-dtr" and "dtr" mean?
<rapha> (assuming "rts" means "reset"?)
<PaulFertser> rapha: assumption is wrong, see the RS-232 signals for both RTS and DTR.
<rapha> "request to send", "data terminal ready". i see. so this rom bootloader method is inspired by rs-232.
cmcmanis has quit [Remote host closed the connection]
cmcmanis has joined #openocd
emeb has left #openocd [#openocd]
zjason has quit [Read error: Connection reset by peer]
zjason has joined #openocd
key2_ has quit [Ping timeout: 252 seconds]
nohit has quit [Ping timeout: 256 seconds]
key2_ has joined #openocd
thinkfat_ has quit [Quit: Konversation terminated!]
thinkfat has joined #openocd
thinkfat has quit [Client Quit]
thinkfat has joined #openocd
captain_morgan has quit [Remote host closed the connection]
captain_morgan has joined #openocd
thinkfat_ has joined #openocd
thinkfat has quit [Ping timeout: 258 seconds]