<karlp>
you can do some static calculations on stack usage, that's indepdnedent of rtos
<karlp>
and there's some methods with stack protection method 1 that are just setting a high water mark,
<karlp>
I imagine the "support" is just looking at the values that freertos can provide via those methods?
<jancoow>
ye, exactly
<jancoow>
doing it manually is a bit more work
<jancoow>
I've some annoying problem but hard for me to debug now
<karlp>
soundsd like they're getting better in clion land, about time
<jancoow>
(with the tools I've on hand now)
<jancoow>
clion is $$
<karlp>
I still see people having all sorts of problems with it.
<karlp>
you can do a fair bit of it by just looking at yoru thread info blocks
<karlp>
and just dumping the memory of the task stack
<karlp>
it won't give you the "x%" summary
<karlp>
also, that page is talking abotu _heap_ usage, not _stack_ usage...?
<karlp>
those are not the same thing...
<jancoow>
lol
<jancoow>
ye
<jancoow>
jetbrains <.<
<karlp>
heap usage is just "which freertos mem mange is in use? -> inspect it's data structure"
<jancoow>
where can I see my thread info blocks?
<karlp>
info threads in gdb should show you enough info on where they are,
<karlp>
you jetbrains does say: "Set configRECORD_STACK_HIGH_ADDRESS to 1, for displaying the task stack info."
<karlp>
so yeah, they're relying on app tracking like anyone else does,
<karlp>
just more prebaked scripting to dig it out.
<jancoow>
I understand
<jancoow>
I was just looking for a tool which can do that with openCOD too
<jancoow>
but can't find an easy one
<karlp>
there's probably a variety of private half polished scripts around
<karlp>
for a lot of people, turning on stack protection methods and then just "is it crashing?" => everyting's fine...
<jancoow>
We have stack protection
<karlp>
I wish clion had better support for makefile projects,
<karlp>
they stuck with cmake only for son long
<Haohmaru>
what exactly is "support for makefile projects" like?
<karlp>
I would want it to be not "we parsed it ant turned it into something else" :) for instance...
<Haohmaru>
o_O
<Haohmaru>
my IDE simply allows makefiles, there's a checkbox and then the IDE no longer builds with its own build system, but just runs the makefile and redirects the output so you can see it
<karlp>
things like that are probably littered all over git hub :)
<jancoow>
cant get the python thingy to work easily unfortinally
<jancoow>
becaues annoying imports with multiple files
<Haohmaru>
snek wrestling begins ^
<karlp>
well, you can buy clion ;)
<jancoow>
I can fix it ;p
<jancoow>
its exactly what I need so
<Haohmaru>
clion sounds like see lion
<Haohmaru>
* sea lion
<karlp>
I think that was the intention?
<Haohmaru>
such dirty intentions
<karlp>
jancoow: I actually think it would be perfectly reasonable for openocd to have scripts like this in contrib
<karlp>
to save people going off and trying to find them
<Haohmaru>
and a script manager that fetches available script with metadata and screenshots and shows them in a GUI and lets you install/remove scripts
<Haohmaru>
this is the new trend
<jancoow>
npm for openocd
<Haohmaru>
well, kicad6 comes with such a thing now
<jancoow>
it does
<Haohmaru>
it's like a mini version of synaptic
<jancoow>
kicad6 also comes with a lot of annoying things
<Haohmaru>
yeah we don't speak about the annoying things outside of #kicad
<jancoow>
karlp thanks a lot mate! The python thingy works
* karlp
cheers
<karlp>
the basic concept is the same for everything, both openocd's rtos support and any other debugger
<karlp>
it's always just a bit of a debate over who exactly is going to reach into memory and decode.
<Haohmaru>
but debugging something that has RTOS is harder, generally, right?
<karlp>
so oocd's rtos support makes the rtos's look like os threads, so gdb facilities for working with multithreads just works out of the box
<karlp>
Haohmaru: not especially, not if you're using an rtos to basically "processes" anyway
<karlp>
you can get into debugging depths if you want to debug os mechanisms for message passing and things, but none of that is really more complicated than message passing without an rtos?
* Haohmaru
hasn't used RTOS yet, nor looked into one too much
<jancoow>
karlp yes the thread thingy works great now too
<jancoow>
I didnt know that existed until an hour ago
<karlp>
you'll run into some weirdness when you load new versions of your dev firmware, as it doens't always get re-synced nicely,
<karlp>
the sync between one place having an elf that doesn't reallllly match what's currently in the flash sometimes does some weirdness, but in general, yeah, it works really nicely, super handy
<bencoh>
the sync issue is something I saw on a few platforms as well (I use to issue monitor gdb_sync / sync)
<bencoh>
is that considered "normal"?
<karlp>
well, I'm not even sure what the workaround is.
<bencoh>
oh, you're only referring to upgrading the firmware
<bencoh>
I was talking about regular use
<karlp>
well, it can only get out of sync when the flash doesn't match the elf.
<karlp>
what sync issues are you talking about?
<bencoh>
something I saw at least on arm64, for some reason gdb doesn't sync registers until I force sync
<jancoow>
karlp ah, after i reset the device, the thread list does not update in vscode / gdb
<jancoow>
seems to remember the old threads
Guest41 has joined #openocd
<karlp>
if you reset it by hand, it had no way of knowing you did that, and yeah, these are where things can get quirky.
<karlp>
I still feel that there's room for improvement in oocd side here, btu there's definitely dragons around with not reading too much into things.
<jancoow>
no I run -exec monitor reset halt
<karlp>
that's going behind gdb's back.
<karlp>
ifyou stay in gdb and jsut do "ctrl-c; run" you should get a better experience.
Guest41 has quit [Ping timeout: 256 seconds]
Guest92 has joined #openocd
<Guest92>
hi all, has anyone here got experiance using a buspirate containing pl2303 with Openocd on windows 10 and has a liitle time to help someone out?
<PaulFertser>
Guest92: what kind of a bus pirate is it? Are you sure it's official?
<PaulFertser>
Guest92: and have you tried using regular buspirate commands with it manually with a terminal emulator?
<Guest92>
its an sandbox version running FW 6.0 which should have openocd support, but when running openocd i just get "could not open seriel port (com port is decalred in buspirate.cfg as buspirate_port /dev/COM1)
<Guest92>
terminal works fine but openocd just wont open, im thinking maybe it becasue the sandbox version uses a pl2303 or would this make no difference
<PaulFertser>
Guest92: on windows you should use '\\.\COM1' as device name I guess.
<PaulFertser>
Guest92: do you mean you're running native OpenOCD or OpenOCD in WSL2 VM?
<Guest92>
like this "buspirate_port \\.\COM1" or just "\\.\COM1", sorry if these seem like basic questions i am very new to this:/
<Guest92>
i tried with the compiled windows verison on the openocd site, i also tried a version i found that specifically states it contains buspirate support
<PaulFertser>
Guest92: ok, so please show the output where you use plain COM1 or probably the UNC notation with those backslashes, you might need to use single quotes for them.
<Guest92>
Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only
<Guest92>
Info : only one transport option; autoselect 'jtag'
<Guest92>
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
<Guest92>
Error: Could not open serial port
<PaulFertser>
Guest92: please use some pastebin to show full -d3 output.
<PaulFertser>
Guest92: btw, did you confirm in Device Manager that it's COM1 ?
<Guest92>
i have confirmed with device manager, i can also connect fine with terminal. just to confrim before i pastebin the full log, in buspirate.cfg it should be like so buspirate_port '\\.\COM1'
<Guest92>
#buspirate_port /dev/ttyUSB0
<PaulFertser>
Guest92: I'd like to see the log with that, yes.
<Guest92>
i guess that means using the buspirate is out of the question then:( thanks for your help and support Paul
<PaulFertser>
Guest92: the last one looks like Cygwin, not native windows?
<Guest92>
im only using windows, i have no experience with Cygwin
<Haohmaru>
are you sure a USB device would appear as COM1 ? ;P~ that's usually built-in serial ports on the motherboard, unless you don't have any or you've done some fancy things..
<PaulFertser>
Guest92: but you linked me to github repo which discusses building OpenOCD for Cygwin.
<PaulFertser>
Guest92: so can you try /dev/ttyS0 ?
<jancoow>
karlp if stack end is not known, what do you think vscode actually means with Min Free Stack
<jancoow>
a bit confusing
<bencoh>
Haohmaru: serial ports show as COM* on windows if they're recognized as such, even if they're usb adapters
<Haohmaru>
i know
<bencoh>
ah, I get your point
<bencoh>
:)
<Haohmaru>
but "bus pirate" smells like a USB device
<Haohmaru>
i've not been reading ^ carefully, just noticed "COM1"
<jancoow>
people use windows? :P
<bencoh>
in the end it shows up as a serial device as well
<bencoh>
jancoow: :)
<Haohmaru>
my point is, the thing may be popping up as COM5
<PaulFertser>
Guest92: your log suggests you're indeed using Cygwin there.
<Guest92>
light on the BP is now red, before there was no change
<karlp>
jancoow: are you _sure_ stack end isn't known? :)
<karlp>
also, could mean anything :)
<PaulFertser>
Guest92: so communication with BP works. What is your target and is it connected and powered atm?
<karlp>
jancoow: there's also -fstack-usage to help calcualte static maximums.
<Guest92>
nothing is connected just yet, i was trying to set it up ready to flash
<PaulFertser>
Guest92: it is ready
<Guest92>
AT91SAM7S256
<Guest92>
im going to erase the AT91SAM7S256 now and attempt flashing, thanks for your help it is much appreciated
<jancoow>
karlp vscode says so
<jancoow>
karlp i think we dont use that marker at the end of the stack
<PaulFertser>
Guest92: let's see how it goes.
<karlp>
you'd have to look at your own linker scripts and see what it is considering and why
<karlp>
this is another place where the tooling is potentially making assumptions that may not be correct to your particular implementations.
<karlp>
what's the target where you have an at91sam7s but onyl a buspirate?
Bertl is now known as Bertl_oO
<Guest92>
i have a device called "carprog" that uses the AT91SAM7S256, i need to flash it with an update but only have the buspirate available to do this. i am literally doing one thing at a time so im now researching on google how to load and flash the file i have with openocd. i know this is way over my head but i have no option but to do it myself
<Guest92>
afaik the only update method is jtag after erasing by using pin 55
<Guest92>
yep thats it
<karlp>
huh, they talk about it havinga "powerful 16bit mpu"
<karlp>
but ok, whatever
<Haohmaru>
lastversion.rar <- ghetto
<Guest92>
ill be honest, that means nothing to me:/ im just following a guide but attempting to use a buspirate instead of wiggler
<PaulFertser>
Guest92: buspirate should be able to do the job as well. What's your current hurdle?
<Guest92>
im now to the final stage. BP is setup with openocd thanks to you, AT91SAM7S256 is erased so jtag is enabled, jtag pins wired up ready to go, im now just reading up how on the commands to select AT91SAM7S256 as my target and start the flash
<Guest92>
does this look correct or am i way off here openocd -f interface/buspirate.cfg -f board/atmel_at91sam7s-ek.cfg -c "AT91SAM7s256.bin verify reset exit"
<karlp>
try putting "program" in front of the binfile name..
<Guest92>
when omitting -d3 it seems the issue is failing to halt the target, i guess this is likely related to the nRST point if so is there a way i can resolve this with the remaining buspirate pins? (again sorry for the stupid questions this and jtag in general is all new to me)
Guest92 has quit [Quit: Client closed]
Guest92 has joined #openocd
<karlp>
have a play with "config_reset none" maybe
<karlp>
or the other config_reset options
nerozero has quit [Remote host closed the connection]
<Guest92>
i tried changing "reset_config srst_only srst_pulls_trst" to "reset_config none" which gives me "how to reset?" error
<Guest92>
do you know if i need to pull nRST on the board to H or L? as at the moment its just floating due to no nRST from the buspirate
Guest92 has quit [Quit: Client closed]
Guest92 has joined #openocd
<Guest92>
if TDI and TDO were inverted could this cause the issue or would i have other issues before this point in the log
<PaulFertser>
Guest92: what's the current state, still same as you described?
<PaulFertser>
Guest92: btw, if you mention my nick in full I get a "bell" and so will reply sooner.
<Guest92>
still the same as my last pastebin log, i have a tried inverting the tdi tdo, held nRST low and high but nothing
<PaulFertser>
Guest92: ok, let me loog at the logs. So do you confirm your buspirate has no reset pin at all? I thought it had one that can be used for target reset?
<Guest92>
i see, thanks for the tip PaulFertser
<PaulFertser>
Yeah, that works, usually IRC clients support Tab-completion to make it faster to not type in full.
<Guest92>
on my travels researching i seen mention that AUX can be used so i have tried that, this aux pin goes high when attempting the write
<PaulFertser>
Guest92: then you need to tie target's TRST high externally, and connect AUX to target's RESET (SRST) and use "reset_config srst_only".
<Guest92>
there is only pin nRST available on the target
<PaulFertser>
Guest92: is it not a JTAG target? Usually JTAG targets have TRST too.
<PaulFertser>
Guest92: I'm checking the buspirate sources to tell if it supports SRST or not.
<Guest92>
thank you PaulFertser
<PaulFertser>
Guest92: do you have a telnet client?
<Guest92>
no, windoes 10 appears to not have it by default. is this needed :/
<PaulFertser>
I see from the sources buspirate has both trst and srst pins.
<PaulFertser>
Guest92: is it hard to install? I'd prefer you having a regular telnet client to try several OpenOCD commands interactively.
<Guest92>
it should be quite simple, ill give it a go, be back in moment
<Guest92>
telnet is now installed PaulFertser
<PaulFertser>
Guest92: ok, so please start OpenOCD without -d3, with "reset_config srst_only", with srst physically connected, without -c program.
<PaulFertser>
Guest92: and connect with "telnet localhost 4444"
<Guest92>
im not sure what srst is PaulFerser sorry
<Guest92>
telnet has conencted, currently i have nRST held high as you mentioned is this correct (there is no point on the target for any other rst only nrst)
<Guest92>
this is my current log without -d3, nRST is held high, "reset_config srst_only" is set, but sRST is not connected as there is no pin for this on the target on nRST PaulFertser
<PaulFertser>
Guest92: srst means full target's reset line.
<PaulFertser>
Guest92: no, OpenOCD should be able to control nRST (SRST), it's TRST that should be held high but I assume the board has it somewhere already.
<PaulFertser>
Guest92: the last output doesn't look like anything proper.
<PaulFertser>
Guest92: make sure you properly connected ground, tms, tdi, tdo, tck.
<Guest92>
i will double check them now
<PaulFertser>
Guest92: of course tdi should be connected to tdi, tdo to tdo.
<PaulFertser>
Guest92: target's nRST should be connected to AUX.
<PaulFertser>
(I judge by your config you pasted earlier)
nerozero has quit [Ping timeout: 240 seconds]
<Guest92>
i have connected buspirate AUX to target nrst, changed voltage reg-on, normal mode, and pull ups disabled this is now my output https://pastebin.com/5UH0g90V PaulFertser
<PaulFertser>
Guest92: ok, looking...
<Guest92>
thank you for having so much patience with me PaulFertser
<PaulFertser>
Guest92: please connect with telnet now and try "halt" there, and see what it prints both in openocd window and in telnet.
<Guest92>
Info : Halt timed out, wake up GDB.
<Guest92>
Error: timed out while waiting for target halted
<PaulFertser>
Guest92: btw, do not add any "reset_config" command at all.
<PaulFertser>
Guest92: and please use stock config, that means just -f target/at91sam7sx.cfg
<PaulFertser>
Guest92: and retry and show new output if it differs
<PaulFertser>
Guest92: better include the invocation command line
<Guest92>
what is the invocation command PaulFertser
<PaulFertser>
Guest92: how you start openocd, with all the command line options
<PaulFertser>
Guest92: hm, it probably looks like TDI is not connected at all. Can you retry the same command with TDI disconnected and see if it makes any difference?
<Guest92>
no problem 2 mins
<Guest92>
with TDI disconnected the result is the same
<Guest92>
could this be a failed erase? jtag is disabled but it should be erased after i jumped pin 55
<PaulFertser>
Guest92: no if with TDI disconnected it's exactly the same it means your TDI wasn't really connected in the first place.
<PaulFertser>
Guest92: or driven by buspirate.
Guest92 has quit [Quit: Client closed]
Guest92 has joined #openocd
<Guest92>
i resoldered all connections and ensured there is no shorts from lifting pin55, still the same outcome. Thanks for your help and support PaulFertser it has been highly appreciated, im going to give my head a rest for the night now as its late here but i will try again tomorrow starting fresh