<pepeIO>
Hello. Is there a port to stm32 somewhere lying in the dark? I looked around, in order to avoid having a full blown pc to act as a remote debugger. Found nothing yet.
<Xogium>
huh ? Openocd supports lots of stm32 out of the box ?
<pepeIO>
no i mean to run openocd ON the stm, network on one side, stlink on the other.
<pepeIO>
or maybe i did not understood your point
<Xogium>
hmm I'm confused
<pepeIO>
my fault, certainly
<Xogium>
what do you try to do ?
<pepeIO>
i am doing remode debugging of some hardware. Actually i have a linux box running openocd and a stlink connected to it
<Xogium>
connect stm32 to host pc and use openocd to flash/debug ?
<pepeIO>
i want to get rid of the bulky pc
<Xogium>
oh so you want to know if there's networking support in openocd ?
<pepeIO>
there is.
<pepeIO>
i use it, it's ok and i love it
<Xogium>
so… what are you trying to know ? Sorry… I'm a bit slow today haha
<pepeIO>
i want to eject the bulky linux pc and run openocd on a much smaller target that has usb and lan too, like some stm32F4 for example
<PaulFertser>
pepeIO: there's blackmagicprobe, have you considered it?
<PaulFertser>
pepeIO: how do you plan to connect to that stm32 board?
<Haohmaru>
pepeIO openocd is written to run on "computers" .. you know, with an OS
<pepeIO>
blackmagicprobe.. let me check
<Haohmaru>
sure, it's only CLI, no GUI, but still
<pepeIO>
Haohmaru: yes, totaly understood that. Does not make it impossible though.
<Haohmaru>
yeah, but.. how would it look like?
<Haohmaru>
a board with "stm32" on it, connected to the target on one side, and connected to .. a computer?
<Haohmaru>
via tcp/ip?
<pepeIO>
Haohmaru yes,
<pepeIO>
Haohmaru the target or a stlink. The blackmagic probe coulbe nice, but it's still usb
<Haohmaru>
well, you could.. use one of those SBCs (which have usually some linux-ish OS) and run openocd on that
<Haohmaru>
people do this
<Haohmaru>
..already
<pepeIO>
i have a little stock of raspberry piw2 but they are pretty scarce. I have somre STM32 lying around than that.
<pepeIO>
* more
<pepeIO>
so what i get from this is that except haveing something running at least linux, i'm out of solutions at the moment, right?
<Haohmaru>
well openocd isn't written to run on baremetal
<Haohmaru>
but it's.. open..source.. so it could be changed ;P~
\dev\ice has quit [Quit: leaving]
<Haohmaru>
if there's some brave coder with spare time
<pepeIO>
well if i had time to make a little product to sell and at least make enough to fund the dev, that is something i would do.
<pepeIO>
or maybe the other way around.. get funds for the project and do it if enough people get interested.
<Haohmaru>
don't look at me, i'm merely a user
<pepeIO>
if it solves my problems, it could also solve others
<pepeIO>
haha
<Haohmaru>
but there are a few openocd devs here
<PaulFertser>
pepeIO: so do you plan connecting via Ethernet to that stm32 board?
<Haohmaru>
for donations you could always check the official website
<pepeIO>
PaulFertser yes
<PaulFertser>
pepeIO: so why not just use BMP code and add Ethernet support to it?
<pepeIO>
yes, could be a way. i was thinking about it.
<Haohmaru>
he has spare chips, he wants to put them on boards!
<Haohmaru>
now don't tell me your "stm32s" are some of those smallest ones, cortex M0
<pepeIO>
yes, too, but if there is a broader solution to implement, and already have people interested in that solution, maybe an extention to it would do the trick
<pepeIO>
Haohmaru nah, there are legit F4
\dev\ice has joined #openocd
<Haohmaru>
got ethernet periph too?
<pepeIO>
i have some Phys also, yes
<Haohmaru>
okay then
<Haohmaru>
tbh i'm not sure what you gain out of this?
<pepeIO>
maybe i could just do a very specific lan to serial adapter to connect to a BMP... that would be simple and fast
<Haohmaru>
a debugger is already not very cheap, even tho openocd is doing a lot of the real "work"
<pepeIO>
open the gdb port on lan and relay all data from and to usb
<Xogium>
honest, I'd just uns a rpi for this…
<Haohmaru>
those debuggers which have everything in them (and thus you don't need openocd) would be even more $$$
<pepeIO>
Xogium sure.. you have some?
<Haohmaru>
so you wanna make a $$$ kind of debugger
<Xogium>
pepeIO: I thought you said you had some ? I have a whole bunch of sbc running linux, no rpi, but still sbc and can run openocd :)
<Xogium>
I'm not criticising here btw just suggesting
<pepeIO>
Xogium yes, i have some. But they are so hard to get that i would only use them if there are no other ways. Actually, the code and pcb for a net/serial bridge for it might just be peanuts to code and manufacture.
<Xogium>
it sounds like it would be much, much less complicated
<pepeIO>
Xogium np, i get that
<karlp>
pepeIO: using any SBC or any old router running openwrt is _far_ easier to set this up if you want to _use_ it, IME,
<karlp>
if you want a project, knock yourself out :)
<karlp>
there's a "remote bitbang" interface in openocd already, that does something like this, iirc, but you have to provide a lot of the pieces yourself
<karlp>
I remember seeing some esp32 project that was implementing jtag as well, but it probably doesn't have the full breadth of target support of openocd and friends
<pepeIO>
Haohmaru: i have some specifics i did not tell you about. i work for a company that makes sensitive systems, no space inside, everything is sealed and proprietary. I would not be able to put a dozen rpis inside the "thing".
<Haohmaru>
you need a debugger in the final device?
<pepeIO>
Haohmaru: no during dev and field tests only
<Haohmaru>
i still wonder, why does that debugger have to contain all of openocd
<pepeIO>
karlp oh, thanks, i'll look at esp32, just in case
<Haohmaru>
why not also put mr PaulFertser in the debugger ;P~
<karlp>
it's a little hard to search for, so I can't find the one I'm looking for, but it was what you want, designed to provide remote jtag to another target.
<pepeIO>
Haohmaru it has all i need. why not, then?
<karlp>
lots of ep32 stuff is using esp32 itself to provide debugging to itself.
<karlp>
and is heavily targetted/locked to esp32.
<Haohmaru>
what if you need a crowbar one day? ;P~
<Haohmaru>
or a can opener
<pepeIO>
Haohmaru then that will be time for a refresh
<karlp>
but again, if you want to use, rather than build, _any_ linux sbc is simple and proven and used already.
<karlp>
doesn'thave to be a pi, can ben ~anything
<karlp>
I have an old mips router with a usb port in the office doing it, as openocd is packaged for openwrt.
<pepeIO>
karlp yeah, i know. i would if i could. Both availability and space forbid me to do so.
<Haohmaru>
do note that openocd is being developed and.. it changes from time to time, i'd speculate that openocd will be getting bigger
<karlp>
space? are you serious?
<pepeIO>
physical space
<Haohmaru>
while a debugger, if it does only simple things, and if it doesn't have much bugs - doesn't need to change that much
<Haohmaru>
btw, an ethernet jack is bigger than a USB micro-B
<karlp>
that's why I loled at "can't do linux because of space" :)
xmszkn_ has left #openocd [#openocd]
<Haohmaru>
pepeIO if you had this "stm32 board running openocd", you might need to also carry around another debugger and a computer in case you have to recompile the first one's firmware to the current version of openocd
<karlp>
pepeIO: you're still the one who knows _your_ space restrictions, i shouldn't lol too hard,
<Haohmaru>
..in the field
<karlp>
but if you're space requirements are that strict, you're very rapidly departing from use, and back into build.
<karlp>
also, I don't get why you would need to put "a dozen" inside "the thing"
<Xogium>
yeah there's that too, the other stm32 will need st-link and something to reprogram it… in the first place
<Xogium>
or black magic probe
<karlp>
Xogium: nah, use the rom bootloader
<Xogium>
oh, you can do that ? I didn't know…
<Haohmaru>
still need to recompile the firmware.. in the field
<karlp>
what?! why compile in the field?!
<Haohmaru>
karlp suppose he makes a firmware now.. two years later, he goes in the field with this, but something isn't quite working, he comes here for help, PaulFertser asks "what version of openocd is this?" "old" "can you try with the current dev version?" "ugh.."
<pepeIO>
i have multiple STM in the thing, and all on seperate sub assemblies that have no spare communication channel for me, except eth.
<Haohmaru>
maybe it's not openocd's fault, but.. "can you try a different version" is a very innocent suggestion right now, isn't it
<pepeIO>
the field is only during tests. Once thing is validated it will run for decades
<pepeIO>
and not change
<karlp>
pepeIO: so how were you planning on debugging it anyway, if you only have ethernet?
<Haohmaru>
okay, i just wanted to mention
<karlp>
we seem to have gone in circles
<pepeIO>
nah, i think i have a workable solution...
<Haohmaru>
circles are perfect
<pepeIO>
^^
<pepeIO>
thanks a lot guyz for your very precious inputs
<pepeIO>
guys.. :s
<pepeIO>
time to head to component stock and check if i have enough
<pepeIO>
have a nice day, wherever you are.
<pepeIO>
and whenever your day is
<Xogium>
pepeIO: you too :D
pepeIO has quit [Quit: Client closed]
Bertl_zZ is now known as Bertl
wingsorc has quit [Quit: Leaving]
<borneoa_>
Too late to reply to pepeIO, but openocd can run over Linux on RPi and on stm32mp1 boards. Plus, upstream in Linux kernel there are also some cheap stm32 MCU, F4 and H7. They require boards with some SDRAM, Linux needs more memory than the one embedded in the MCU.
<Haohmaru>
he supposedly has some cortex M4* stm32
<Haohmaru>
don't think he mentioned what kind but i think he said they got ethernet (maybe)
cyrozap has quit [Ping timeout: 260 seconds]
cyrozap has joined #openocd
<cambrian_invader>
there's a nommu Linux port for some stm32f4 stuff iirc
Bertl is now known as Bertl_oO
merethan has joined #openocd
<merethan>
"this is the place to discuss all things OpenOCD"
<merethan>
Happy to be in the right place :P
emeb has joined #openocd
Hawk777 has joined #openocd
<merethan>
I can feed openocd an /elf file right?
<merethan>
.elf
<karlp>
sure.
<karlp>
to the program command at least.
<merethan>
Excellent.
<merethan>
Not it got written to flash as it is binary on disk :P
<merethan>
I now have a ST-Link because my employer gave me one for the project.
<merethan>
If I buy one myself, which one should I get?
<karlp>
the one that comes on the nucleo/discovery for the target you'r egoing to be working with?
<Xogium>
mm hmm I like the st-link v3 mini ;) but that's just me
<Xogium>
or if it has built-in, sure :D
<karlp>
v3 is locked to only st devices,
<karlp>
so unless you need the speed that v3 can _potentially_ offer, I'd not bother with it
<Xogium>
hmm is it ?
<Haohmaru>
yeah, but it's very small and very cheap
<Xogium>
and what do you mean by st devices ? Like only their dev kits ?
<Haohmaru>
so if you're fine with ST-only targets, you could pick that one
<Haohmaru>
only ST MCUs
<Xogium>
ah
<karlp>
stlink v2.1's onboard useful dev boards are also super cheap...
<Xogium>
I didn't know st-link could be used with other mcu, to be fair
<Xogium>
or well, I guess failing this there's always black magic probes
<Haohmaru>
Xogium cortex-m use a program/debug interface by ARM, it should be the same no matter which $vendor the chip comes from, this means one debugger could support them all
<Xogium>
ah, I see
<Xogium>
makes sense
<Haohmaru>
except, some debuggers ask "which $vendor are you from?" "not-the-right-one" "oh? is that so? send_usb_error();"
<Xogium>
and I just realized the board I bought here which is based on stm32 has… jtag/swd pads
<Xogium>
nothing soldered. Erk
<Haohmaru>
i too have a stlink3 mini
<Haohmaru>
which gathers dust
<Haohmaru>
but at least it was cheap, even tho it's official.. legit.. bought it from mouser
<Xogium>
aw, poor stlink
<Xogium>
comes with some sort of cable, doesn't it ?
<Xogium>
your board's got to have the proper connector for it, I guess ?
<Haohmaru>
yest, the 2x7 "STDC" 1.27mm pitch one
<Haohmaru>
* "STDC14" i mean
<Xogium>
is the pinout to make such things exposed on a board available somewhere, do you know ?
<Haohmaru>
that's basically the normal ARM SWD in the middle 2x5 pins, then two pins on one side for nothing, and two pins on the other side for a UART TX/RX
<Xogium>
neat
<Haohmaru>
that's what i thought too
<Xogium>
having usb 2 speeds is also very very good in my book. I mean, maybe not on a mcu, given that apps are so tiny it wouldn't matter if you have it, but on targets like mp1, woohoo
<borneoa_>
cambrian_invader: yes, the port nommu is in upstream kernel. But only few boards with external SDRAM can be used.
<cambrian_invader>
clearly the solution is a nuttx port :)
<Xogium>
cambrian_invader: what you doing ?
<cambrian_invader>
Xogium: just commenting on borneoa_'s comment from before
<Xogium>
says the one that got amused running linux on stm32f769 dev kit…
<Xogium>
hey I still managed to get 10 mb of ram free after that, even
<Xogium>
I wanted to play with XIP but never managed
merethan has quit [Remote host closed the connection]
<borneoa_>
Oops, mistake. The boards are not listed there. Must be searched in arch/arm/boot/dts/stm32*
merethan has joined #openocd
<Xogium>
I believe f429, f746 and f769, and h750 ? Not too sure
<Xogium>
still… that was rather fun, plug polwer in via PoE, bam login prompt in under 3 seconds
<Xogium>
*power
<borneoa_>
The supported chips are in the link above. There is also h743
<Xogium>
but linux is kinda underdeveloped on that board… Probably because there isn't much use for it. No ethernet, no qspi flash, and I believe not even audio or usb
<Xogium>
I also tried to experiment and see if I could just use zram to boost the ram a bit… Nup. Turns out zram depends on some options which itself depends on having a fully functioning MMU, MPU isn't enough
nerozero has quit [Ping timeout: 248 seconds]
Guest30 has joined #openocd
<borneoa_>
Yes, the MCU boards miss many interfaces. The eval are way too expensive. It depends on the target application, but the stm32mp157f-dk2 or the RPi could fit better
<Xogium>
indeed
<Guest30>
hi
<Xogium>
the dk are generally okay, but the full eval platforms are really really too expensive. Even for mp1 family, I find
<borneoa_>
When I get some time I want to see if I can get a ethernet to USB out of a inexpensive MCU boards
<Xogium>
still, I did this mostly for the hell of it, and learning experience. Not cause it was useful in any way hehe
<Xogium>
borneoa_: do you know if st plans on moving the mp15x to kernel 5.15, or will it stay on 5.10 until the st kernel is no longer necessary ? Although… this could change now that there's a new family in the mp13x
<borneoa_>
Xogium: I think there are other boards stm32mp1 around, not from ST. But never checked the price. There are even tiny modules to build your own board
<borneoa_>
Yes, 5.15 is on the way
<Xogium>
oooh awesome
<borneoa_>
It's taking a little more because there is a new release of openembedded/yocto and the idea is to package all together. Mess of dependencies.
<borneoa_>
Yep, I believe mp13 would be directly 5.15
<Xogium>
I want one of these, someday
<Xogium>
yeah I like sbc ;p
Haohmaru has quit []
<merethan>
How about low-level ones that have OpenOCD do all the work?
<merethan>
(Are those bit-banging over USB CDC / FTDI?)
<merethan>
As <Haohmaru> mentioned: "not-the-right-verndor-id" "oh? is that so? send_usb_error();
<merethan>
Like to have a "universal" one.
<Xogium>
I suppose that they do this, but I don't know
merethan has quit [Read error: Connection reset by peer]
Guest30 has quit [Quit: Client closed]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #openocd
wingsorc has joined #openocd
sbach has quit [Read error: Connection reset by peer]
sbach has joined #openocd
Slide-O-Mix has quit [Ping timeout: 260 seconds]
Slide-O-Mix has joined #openocd
wingsorc__ has joined #openocd
wingsorc has quit [Read error: Connection reset by peer]