<PaulFertser>
zapb__: hey :) I have apm32f103cbt6 here and I think in SWD mode it gives ID register value 0x2ba00477 (original ST part gives 0x1ba01477)
<PaulFertser>
Eh, 0x2ba01477 for SWD
damex has quit [Ping timeout: 240 seconds]
<Haohmaru>
same value with 1 bit changed?
damex has joined #openocd
<PaulFertser>
Haohmaru: yes, as it's a newer revision core
<Haohmaru>
1 bit flipped up like a raised middle finger... is this legal
<PaulFertser>
Haohmaru: it's Cortex-M3 standard ID, and that's just newer revision of it, perfectly fine afaik.
<Haohmaru>
wait, isn't that ID a vendor one?
<Haohmaru>
or is it an ID of the core alone and thus would be identical between vendors?
<PaulFertser>
The latter
<Haohmaru>
so they basically use ST's existing ID
<Haohmaru>
or an ID which ST would've used if they had their chip with that revision of the core too
<Haohmaru>
i'm not like a fan of ST, but i still have mixed feelings about those who pretty much clone chips in a way that it's not very clear that they are clones
<Haohmaru>
if you can make decent chips - put your name on them, make your sh*t good
<PaulFertser>
Haohmaru: you do not listen. It's ARM's ID.
<Haohmaru>
oh, sorry
<PaulFertser>
And they do put their own name on it.
<Haohmaru>
right, but i've seen some who don't
<Haohmaru>
specifically for STM32 since it's very popular
<Haohmaru>
who knows about the others
<Haohmaru>
and also being clones or very close to clones doesn't give them an excuse to not make decent datasheets and docs and stuff
marex has quit [Server closed connection]
marex has joined #openocd
<Haohmaru>
PaulFertser, but i hope there's an ID of the actual whole chip which can be read by the debugger to recognize SAMD21G15WHATEVER from <insert_stm32_cortex-m0+-here>, right?
<Haohmaru>
in an easy way hopefully
<PaulFertser>
Haohmaru: alas no, there's no standard way to identify Cortex devices from different manufacturers
<Haohmaru>
bluh
<Haohmaru>
humans, can't we agree to agree on basic things
<Haohmaru>
i wonder if "more open" architectures would have a "nicer attitude" for such things
<Haohmaru>
risc-v maybe, i wonder if i should be excited about those for my kind of purposes
<Haohmaru>
or should i be hoping for cortex-M85 instead
KindOne has quit [Server closed connection]
KindOne has joined #openocd
wkoszek has quit [Server closed connection]
wkoszek has joined #openocd
karlp has quit [Server closed connection]
karlp has joined #openocd
shibboleth has joined #openocd
Kebianizao has quit [Server closed connection]
Kebianizao has joined #openocd
jn has quit [Server closed connection]
jn has joined #openocd
jn has joined #openocd
slobodan has joined #openocd
MGF_Fabio has joined #openocd
jancoow has quit [Server closed connection]
jancoow has joined #openocd
slobodan has quit [Quit: Leaving]
slobodan has joined #openocd
shibboleth has quit [Quit: shibboleth]
xantoz has quit [Server closed connection]
xantoz has joined #openocd
NishanthMenon has quit [Server closed connection]
NishanthMenon has joined #openocd
nerozero has quit [Ping timeout: 268 seconds]
vfazio has quit [Server closed connection]
vfazio has joined #openocd
akaWolf has quit [Server closed connection]
akaWolf has joined #openocd
shibboleth has joined #openocd
jybz has quit [Excess Flood]
jybz has joined #openocd
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openocd
uartist has quit [Server closed connection]
uartist has joined #openocd
MGF_Fabio has quit [Ping timeout: 252 seconds]
van has quit [Server closed connection]
van has joined #openocd
silurian_invader has quit [Server closed connection]
silurian_invader has joined #openocd
dliviu has quit [Server closed connection]
dliviu has joined #openocd
Ivan0v has joined #openocd
shibboleth has quit [Remote host closed the connection]
shibboleth has joined #openocd
shibboleth has quit [Remote host closed the connection]
zkrx has quit [Server closed connection]
zkrx has joined #openocd
gzlb has quit [Ping timeout: 268 seconds]
gzlb has joined #openocd
Ivan0v has quit [Remote host closed the connection]
slobodan has quit [Quit: Leaving]
slobodan has joined #openocd
<zapb__>
PaulFertser, wait, you mean the config is wrong?
<karlp>
as best i can tell, _most_ of the tap ids in openocd cfgs are wrong, and just copied, because they'r eonly used in jtag mode, and most people use them in swd.
<zapb__>
I thought I double checked it, does OpenOCD raise a warning if the ID is wrong?
<PaulFertser>
zapb__: the config as you offer it in the patch seems to be wrong to me as it's using same ID for both SWD and JTAG and SWD ID doesn't match what I saw.
<zapb__>
PaulFertser, thanks, I think I have a board here - will check it later
<PaulFertser>
zapb__: yes, it complains for me when I'm using stm32f1x.cfg against geehy f1 (at least with stlink adapter)
<zapb__>
PaulFertser, okay, strange
<zapb__>
thanks for the pointer
<PaulFertser>
zapb__: thank you for taking proper care of adding those new geehy devices and for everything else you're doing of course.
<PaulFertser>
karlp: it's strange, it certainly refused to proceed for me with SWD (with stlink hla).
<PaulFertser>
Guess that explains it, no check in regular SWD mode, just in hla.
<karlp>
i think those checks are kinda ... not useful.
<karlp>
I mean, check it's a cortex m, but chekcing for a patch level, and getting the right taps or jtag and swd separately is just unhelpfully constricting config files.
<PaulFertser>
But SWD is not only for Cortex-M, what if you have have two different connectors on your board, one for an MCU and one for an ARM SoC, and you connect to the wrong SWD connector and with this check you get an error. Doesn't sound to be bad for sanity checking.
<karlp>
as I've said before, I'd like those sorts of configs to be the ones that need config, and openocd to head more in teh direction of "please just connect and tell me what you found and make it work"
<karlp>
instead of piling jtag and swd dap tap codes into multiple separate files all the time
<karlp>
stellaris.cfg does this right, supports a huge range of parts.
<karlp>
st parts.... don't
<PaulFertser>
It might make sense what you suggest...
<karlp>
st parts need separate configs, even if it's the same flash driver, so that the "name" can be set properly, and so that these tap ids can be "right" for "sanity checking"
<karlp>
probe time is _cheap_ even if it looks at a _bunch_ of memory places, and can't support everything.
bryanb has quit [Server closed connection]
bryanb has joined #openocd
<zapb__>
karlp, yes, I think OpenOCD should *at least support* some kind of interactive mode like the J-Link tools
<zapb__>
PaulFertser, should be fixed now
pedro_a has joined #openocd
flatmush has quit [Server closed connection]
flatmush has joined #openocd
<karlp>
jlink is _worse_ imo, but I've not used it extensively. having to select a part, and having it make me choose from a full MPN list of every part every made in the world is.... horrible.
<karlp>
teh flat out refusal to answer -h, or have anyway of finding out command line options available without goign to the internet doesn't win points with me either.
<karlp>
or the UI that generates a command line, but doens't inform you of options like rtos support via .so files.
<bencoh>
I'm not a great fan of their commandline either, but I have to admit the plug&play apect feels kinda nice sometimes
lh has quit [Server closed connection]
lh has joined #openocd
slobodan has quit [Ping timeout: 245 seconds]
wingsorc has joined #openocd
crabbedhaloablut has quit []
<zapb__>
yes, it's not great but it guides you through a few steps like interface selection, part selection etc. which is much easier for new users than loading multiple config files via command line arguments IMO