11:41 <PaulFertser> To power-cycle stlink on it?

11:41 <PlasmaHH> no to power cycle the STMU5A5

11:51 <PaulFertser> I'm trying to download cubeide from st.com for the first time in my life (my father wants to try using vendor tools). It's rage inducing on so many levels that it's hard to believe. It starts with st.com loaded with JS disabled gives me a cookie that makes the website not answer at all after I enable JS for it. And then it continues with more nonsense. Absolute bonkers, insane and disgusting.

11:51 <PaulFertser> PlasmaHH: what part of the target MCU behaves differently for you with POR compared to external reset line?

11:52 <PlasmaHH> PaulFertser: accessing any TPIU register when the trace enable bit is not set locks up the mcu

11:52 <PaulFertser> PlasmaHH: and it doesn't recover even with external reset line pulsed?

11:52 <PlasmaHH> correct

11:52 <PaulFertser> :/

11:53 <PlasmaHH> is the same among all STM32 I had access to ..

11:54 <PaulFertser> Hm so the watchdog would not be able to recover it from this state either? So you can in software lock the MCU in a way that no watchdog can recover it?

11:54 <PlasmaHH> correct again

11:54 <PlasmaHH> and that all by trying to read some data

11:57 <PaulFertser> Errata-worthy stuff

11:57 <PlasmaHH> according to ST this works as intended

11:58 <Haohmaru> sometimes i slap a mains power extender thing on the desk, one that has an ON/OFF switch

11:58 <PlasmaHH> documentation seems to somewhere say that before accessing TPIU registers you need to enable that bit

11:59 <PlasmaHH> Haohmaru: yeah have plenty of that stuff but the nucleo boards are connected to the pc via usb... so I would need some remote switchable usb port

11:59 <PlasmaHH> of course I could somehow configure the board witht hat power measurement jumper and slap a relay in there ^^

12:00 <PlasmaHH> but usually I dont remember to do any of that before it happens at least once ;)

12:00 <Haohmaru> does it transfer data thru that USB?

12:00 <PlasmaHH> yeah, its the stlink debugger connection

12:00 <Haohmaru> meh, that'd suck

12:00 <Haohmaru> that's why i prefer having a stand-alone debugger

12:01 <Haohmaru> and then one of these on the desk: https://drebisimo.com/37669-large_default/razklonitel-s-klyuch-3-gnezda-i-15-m-kabel.jpg

12:01 <PlasmaHH> Haohmaru: that doesnt help much if the desk is 30km away ;)

12:02 <karlp1> (this is why i built a usb hub with per port power switching)

12:02 <Haohmaru> .../razklonitel-s-klyuch-3-gnezda-i-30-km-kabel.jpg

12:02 <Haohmaru> karlp1, this is why i call you mr fancy

12:03 <PlasmaHH> karlp1: remote controlled?

12:03 <karlp1> as much as your usb ports are...

12:03 <Haohmaru> but if you basically turn off the debugger via the "USB" port, the program using it (openocd) wouldn't be very happy about that

12:03 <Haohmaru> when all you wanted was to power-off the target

12:05 <PlasmaHH> Haohmaru: wouldnt have much of a problem with that

12:05 <PlasmaHH> karlp1: i.e. ususally not at all

12:06 <PaulFertser> You can use a proper USB hub where you can control per-port power.

12:07 <Haohmaru> i think a bigger problem would be the USB-serial (which is available in my daplink), when my serial port program has opened it, and the USB device goes away and then comes back - it seems linux doesn't re-enumerate it under the same /dev/path, so it turns into a different number

12:09 <PaulFertser> So talk to it via by-serial path.

12:09 <Haohmaru> my program ain't so clever

12:09 <PlasmaHH> Haohmaru: within my own programs using anything serial I try to use the serial number of the adapter if possible

12:10 <Haohmaru> i don't know about any of that, it's a "serial port lib" written by me that supposedly works on M$OS/linux/crAppleOS

12:10 <Haohmaru> very long ago

12:10 <Haohmaru> it just has enough things to open a port and send/receive data

12:11 <PlasmaHH> if its by you it should be a perfect opportunity to add that serial number feature ;)

12:12 <PlasmaHH> of course, if your usb serial adapter doesnt have a serial number...

12:13 <Haohmaru> the rest of it is wxWidgets, it looks sorta like this: https://i.imgur.com/ztSt6gP.png

12:14 <Haohmaru> well, no idea, i use a "daplink" SWD debugger which includes a virtual-serial-port in the same USB

12:14 <Haohmaru> linux enumerates it as "/dev/ttyACM0"

12:15 <PlasmaHH> look in dmesg when you connect it, when it has a serial it will tell you tehre

12:15 <Haohmaru> but when i keep it open via my program and unplug/replug the debugger - my program is sorta stuck while linux enumerates it as "/dev/ttyACM1"

12:17 <PlasmaHH> (for the remote controlled usb hub thing the funny thing is with where it is connected to, when I try to disable power with e.h. uhubctl it will lose the usb conneciton but still provide power )

12:17 <Haohmaru> doh

12:18 <Haohmaru> can you break-off the debugger part of that board?

12:19 <PlasmaHH> with a hacksaw probably :P

12:20 <Haohmaru> ehm, no then, you don't want FR4 dust ;P~

12:20 <Haohmaru> FR4 dust ain't cool

12:21 <Haohmaru> the next possible thing is potentially to find something on the board which can turn OFF the power to just the target

12:22 <PlasmaHH> as said earlier, if I had physical access and anticipate such a thing I could slap a relay board into the power path

12:23 <Haohmaru> oh, the thing is not there with you?

12:23 <Haohmaru> well..

12:24 <PlasmaHH> yeah 30km away... had to send out a coworker to reset it...

12:24 <Haohmaru> using thick enough metal rod.. cause a short circuit near the Power Plant ;P~

12:24 <PlasmaHH> ups and diesel..

12:35 <PaulFertser> PlasmaHH: consider USB hub https://github.com/mvp/uhubctl

12:35 <PaulFertser> Ah, I didn't read carefully, you're aware.

12:36 <PlasmaHH> painfully, yes

12:51 <karlp1> PlasmaHH: you wanted it to be power controllable over stlink, so ... you alreayd have that access.

12:52 <karlp1> if you have remote access to the stlink to do your desired "power cycle" you have remote access to the usb port already?

12:53 <PlasmaHH> karlp1: I dont have any means to disable the usb port power though

12:53 <karlp1> yes, you would need a suitable hub.

12:54 <karlp1> also suitable control software. linux has done some things recently where they try and disconnect the _USB_ layer, instead of the port power switching, there's conflicting goals and conflicting hardware in this space.

12:55 <PlasmaHH> karlp1: and for some apperantly some work necessary :P https://github.com/fifteenhex/diyppps/blob/master/5_after.jpg

12:55 <karlp1> it's particularly an issue wiht self powered devices, "some people" "expect" that thiings like uhubctl can reset those devices.

12:56 <karlp1> that's an extremely narrow specific type of fix.

12:56 <karlp1> you can just buy ones that do PPS...

12:56 <karlp1> if this is something you actualyl want.

12:57 <Haohmaru> mmmm, is that hot-snot on the chip?

12:57 <PlasmaHH> uv hardened glue I think

12:58 <PlasmaHH> the other pics on that repo show the tremendous soddering skills

12:58 <karlp1> lot of work to skip just buying a pps hub.

12:59 <PlasmaHH> 10 minutes if you know what you do vs. waiting for days until the hub is delivered...

12:59 <Haohmaru> this sort of "mod" wouldn't be 10 minutes for me x_x

13:00 <Haohmaru> i hate these kinds of things

13:00 <PlasmaHH> so you make it in 2?

13:00 <Haohmaru> nah, i'd smash it and build another one ;P~

13:00 <PlasmaHH> I have no idea why they removed part of the chip...

13:02 <Haohmaru> a collegue here used to do similar kinds of mods, using 0.112mm coated wire (that's used for making coils)

13:02 <Haohmaru> i don't have the eyeballs nor the patience for this kind of sh*t

13:03 <PlasmaHH> yeah I once had to solder a few of these in dead bug configuration: https://github.com/fifteenhex/diyppps/blob/master/5_after.jpg

13:03 <PlasmaHH> nah wrong link

13:03 <PlasmaHH> https://www.sitime.com/products/32-khz-oscillators/sit1533

13:41 <karlp1> they ground off the chip to have bigger pads to solder onto.

13:41 <karlp1> it's clearly osmeone who reworks a lot :)

13:41 <karlp1> waiting days for hte hub to arrive vs ordering the parts you actually need and can rely on being repeatable vs having joerework custom make for everything :)

13:42 <Haohmaru> 1) order proper hub. 2) get a pepsi. 3) open the pepsi. 4) drink the pepsi

13:43 <PlasmaHH> karlp1: sometimes people need to get shit done first and can then wait for the proper solution to arrive later

13:56 <karlp1> the way you presented that solution seemed like that was something you felt should be done, but maybe I just misinterpreted :)

13:59 <Haohmaru> this won't be a problem when they invent the teleport... and/or the time machine ;P~

14:13 <PlasmaHH> Haohmaru: if they then also prevent aging I could be able to do stuff in 1024 parallel threads

16:56 <zapb__> sys64738, saml11 behaves as expected here, you cannot flash because there is no flash driver implemented

16:56 <sys64738> that I gathered, but I wouldn't expect it to choke on *trying to reset the CPU*

16:57 <sys64738> (similarly, trying a "reset halt" command fails as well)

18:51 <PlasmaHH> So funny thing... I wonder if anyone can guess what happened... I have an STM32U5A5 nucleo and playing with SWO on it and have some data output in regular intervals which outputs fine, and some data that is triggered only when the blue user button is pressed and that is almost always garbled...

19:56 <Hawk777> PlasmaHH: How are you outputting the data, are you using TRACESWO?

19:59 <Hawk777> I wonder if this message <https://sourceforge.net/p/openocd/mailman/message/37868251/> would help; it’s for H7 not U5A5 but I wonder if something similar might have happened.

19:59 <Hawk777> Obviously the same commands wouldn’t help, but at least the idea.

19:59 <Hawk777> Specifically the PS part.

20:00 <Hawk777> If you’re ever halting or modifying the relevant PLL output, that might affect it.

20:30 <PlasmaHH> Hawk777: PLL is already a good guess... the button on the nucleo uses the pin besides the 32khz oscillator input and when you push the button the frequency gets thrown out for a moment causing the swo uart timings to be all over the place

20:53 <Hawk777> Ah, that sounds like a problem.