rkta has quit [Read error: Connection reset by peer]
rkta has joined #openocd
tsal_ has joined #openocd
tsal has quit [Ping timeout: 245 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
tomtastic_ has quit [Ping timeout: 244 seconds]
tomtastic has joined #openocd
<borneoa_>
olerem: I will merge only 2 of them during the weekend. This will simplify the work in case of regression. The other 2 can wait a little
<olerem>
borneoa_: ok
nerozero has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
tarekb has joined #openocd
tarekb has quit [Read error: Connection reset by peer]
tarekb has joined #openocd
nerozero has quit [Quit: Leaving]
nerozero has joined #openocd
Guest73 has joined #openocd
ConstellationLab has joined #openocd
<ConstellationLab>
Thanks for the great ideas yesterday, all. Problem solved with help from assistance from Tarek! For the record, if anyone else has the same problem, it's very important to include the command stm32l4x unlock 0 and stm32l4x option_load 0 (and probably a reset as well) before the lock bit changes will take effect. The flash probe 0 command makes
<ConstellationLab>
it easy to see the current status. Again, thank you!
ConstellationLab has quit [Client Quit]
<PaulFertser>
I wonder if it means something essential is missing in the docs.
<karlp>
no, I think something was missing from their description :)
<tarekb>
I will check if the texi is missing stgh, maybe a hint that an option_load is needed ...
<karlp>
hey tarekb, where did you get stm device id 0x496 from? you've added it as the code for STM32WB3xx but that's not in any ref manuals I can find? it's just 0x494 for the WB1xx and 0x495 for both 3x and 5x?
Guest73 has quit [Quit: Client closed]
<Haohmaru>
from <confidential.txt> ?
<tarekb>
Hi karlp, the device 0x496 have just been dropped by ST, for non-public reasons
<tarekb>
and got replaced by 0x495
<tarekb>
I found it non-critical to remove it from openocd, but it could be safely removed
<karlp>
well, it's misleading when the description for it says "WB3x" :)
<karlp>
it will never hit, true, but it means 3xs always report as 5xs, and is confusing for other people reading the code
<tarekb>
yes you are rith
<tarekb>
s/rith/right
<tarekb>
I was waiting for a document update to rise up
<tarekb>
to update the displayed string for that device
<tarekb>
I have using stlink-dap.cfg for so long, so I forgot about the HLA adapter thing
<karlp>
nah, this seems to be a firmware bug in the stlink itself that causes a unexpected handle in openocd.
<karlp>
when I resume, the stlink shows up on usb, and lsusb shows all the descriptors, but it totally fails to actualyl open anything.
<karlp>
and then, if you have a tpiu config, as part of "cleaning up" it tries to deconfigure the stlink trace endpoint, with a null handle.
<tarekb>
oops, seems to be an order thing, actually Antonio can help on this, he reworked the tpiu config and he masters the stlink drivers (I have only added the stlink tcp server)
<tarekb>
but theoritically speacking this 'maybe' could be fixed by changing the cleanup order
<karlp>
yeah, I'm not on master because of other problems, but am going ot have to get master working sooner or later
<karlp>
been running into shitty ITM problems with rust and stm32wb, last thing I needed was oocd being wonky at the same time, so went back to 0.11 :)
<karlp>
blood -werror
<PaulFertser>
Master doesn't build on your system with -werror? Probably we should fix some warning then?
<PaulFertser>
The build server is now running Debian stable but I think I can install gcc and clang from backports.
<karlp>
it's inside jimtcl, but yeah.
<PaulFertser>
jimtcl is going to be bumped soon. But that's a good hint, probably we should disable Werror for jimtcl part.
<karlp>
iirc, we've said exactly that before....
<karlp>
ok, master doesn't check the handle being valid, but it doesn't bother trying to "cleanup" when it couldn't connect, so good enough for now :)
<PaulFertser>
karlp: are you on g++-11 ?
<karlp>
honestly, I neitherknow nor care :) but for you: g++: command not found...
<tarekb>
well #6310 is clean, and could be merged, I think the patch got lost ...
<tarekb>
borneoa_: do you think it could be merged soon ?
<tarekb>
if Oleksih is here, I would love to thank him for reviewing my long STM32L4 driver changes
<tarekb>
thanks olerem:
<PaulFertser>
karlp: I'm checking and I can't see jimtcl getting built with Werror, it's really using its own flags. Can you please tell me more?
<PaulFertser>
tarekb: that's olerem :)
<tarekb>
this serie is one year old, and was stuck in review, thanks to him it's in the mainline
<karlp>
aight, still no damn trace in master.
<tarekb>
I can sleep very happy tonight !!
<karlp>
damnit.
<PaulFertser>
tarekb: why are you checking for hla and not directly for that debug_ap being null?
<PaulFertser>
Is there some idea behind that?
<tarekb>
PaulFertser: I was thinking that CPU2 should not be support using HLA, so I have explicitely added a check on hla
<tarekb>
but both checks should work
<PaulFertser>
tarekb: will the end-user get a clue about what's happening when that check triggers?
<PaulFertser>
Or does it not trigger if upstream configs are used?
<PaulFertser>
tarekb: it's just that I often spend time here dealing with end-users' confusion, hence asking :)
<tarekb>
PaulFertser: with the fix, It wont trigger any issue
<tarekb>
mainly that chunk of code was to support the second core in STM32WL55x devices
<PaulFertser>
tarekb: so basically the flash driver could have been called with the second core being currently active and that's what the check is about?
<tarekb>
yes, correct (adding the precision that the issue occurs only with HLA adapters)
<PaulFertser>
I understand how checking for the active core triggered segfault with HLA, I was just curious about the reason to have that check in the first plac.
<tarekb>
FTR, in STM32CubeIDE we don't use the stlink as HLA Adapter anymore
<PaulFertser>
I see it's all clear now, great.
<PaulFertser>
tarekb: no news regarding stlinkv3? I tried RE it a bit but naive attempts failed and I had to count on someone else for testing the potential mods.
<tarekb>
well, to be 100% precise, the segfault occurs only in the probe function, and not in read_idcode function
* karlp
updates to cubeide 1.7, and it's as busted and horrible as ever.
<PaulFertser>
tarekb: last time Antonio tried it the answer was unclear. I couldn't understand if it's just a bug they introduced and not caring about or if it was made specifically to fuck with the customers.
<karlp>
it's been an ongoing shitstorm with these custom dialogs on linux. gets worse on updates
<karlp>
well, I only need an example for itm, and there's none of them for this board anyway, and i Only need that to try and get master working again, so I'm just going to walk away for the night instead. tired of all this
<tarekb>
karlp: I have tried import "existing projects into workspace " and worked like a charm
<karlp>
I cna get an example that way, but opening the .ioc file is still busted, so all the "cube" bits are still as borked as ever.
<karlp>
this seems to work for some releases for me, then not.
<karlp>
now it's decided it needs stlink server for some reason,
<karlp>
edit properites: set to run via oocd => "stlink server is required"
<tarekb>
oh shit how is that
<tarekb>
this is required only if shared ST-Link is checked