<ldcd>
it ~might~ be possible through FLASH_WRP1AR/BR
<ldcd>
but not in a documented way
<ldcd>
the option bytes live in flash, but idk which page, probably page 128 bank 1
<ldcd>
and in theory WRP are only 7 bits so wouldn't cover it
<ldcd>
but idk if they are actually 7 bytes
<ldcd>
they appear to lock the sysmem region at the factory
<ldcd>
so if there's a undocumented register near those registers set to uh
<ldcd>
0x00830080 or 0x008d0080 then thats how they're doing it and it would probably work
<whitequark>
fascinating
<ldcd>
yeah kinda surprised this is not supported
<ldcd>
i feel like i've seen it on other ST parts?
<ldcd>
is it normal to have uh
<ldcd>
22 copies of the stm32g4 reference manual on your hard drive
<whitequark>
very
<ldcd>
god knows how many on my phone
<ldcd>
ok no i had just misremembered the semantics of the optlock bit, looks like it does the same not super useful thing on g4
<ldcd0[m]>
I do have a decaped g431 on my desk somewhere
<ldcd0[m]>
But it has another die glued on top of it
<duskwuff0[m]>
I think that's universal across all their parts, OPTLOCK is just a molly-guard for the option bytes
<ldcd0[m]>
Yeah I think you're right
<ldcd0[m]>
I don't normally pay much attention to the security features tbh
<ldcd0[m]>
I just assume they're broken
ldcd has quit [Ping timeout: 264 seconds]
<duskwuff0[m]>
it's there to reduce the chances of an inadvertent write by a faulty program, not to prevent deliberate modification
<whitequark>
what's "molly-guard"?
<whitequark>
duskwuff0[m]: yeah inadvertent write is exactly what i am focusing on here
<duskwuff0[m]>
imagine, like, the little flip-up cover keeping you from accidentally pressing an important button
<whitequark>
ah okay
<whitequark>
yeah that would work
<duskwuff0[m]>
OPTLOCK is volatile and defaults to set, you have to go through a little song and dance writing specific values to a register to temporarily clear it
<whitequark>
there is a device on this board. meaning revD0 PCB
<whitequark>
it has I2C address 0b1011001/0x59
<whitequark>
i do not know what it is .
<whitequark>
it's not the TMP112 or the FUSB302 because i physically cut traces to those. it's not PCA6416A because those are very simple and i would expect someone to complain if they listened on some random address
<whitequark>
it's not the FPGA because it appears with the FPGA unconfigured
<ldcd>
and in SC its probably just HS on at whatever the max duty cycle is
<whitequark>
yep I figured it's an active limit
<ldcd>
yeah just surprised it was a whole amp
<ldcd>
and its also not shown in the block diagram which is a touch annoying
<whitequark>
it's surprisingly high, i'd have expected 500 or 600 mA
<ldcd>
yeah same
<whitequark>
the revC3 LDO has a foldback nominally at 300 mA but in practice it's about 500 iirc
<ldcd>
i guess the limit is on the switches
<whitequark>
oh right
<ldcd>
which may exceed 600mA regularly in normal operation
<whitequark>
they oversize the switches because of transient/peak currents even with the average being 300?
<ldcd>
yeah the peak current will be much higher for a given current when doing a large stepdown
<ldcd>
iirc
<ldcd>
maybe i have that backwards
<ldcd>
i think thats right, average current through the top fet needs to be the average output current but the duty cycle the top fet is on for should be the stepdown ratio
<ldcd>
ok yeah max duty cycle under 1MHz operation is going to be uh
<ldcd>
~92% if i'm reading this right
<whitequark>
wait, top fet?
<ldcd>
so ~1.012A current limit in SC if its constrained by the topfet limit
<ldcd>
the one from VIN to SW
<whitequark>
oh it has a synchronous rectifier, siiick
<ldcd>
yeah
<whitequark>
(i have not looked at the buck in any detail)
<whitequark>
> why stop at resistors? Map your configuration to S-parameters and make the user attach an appropriate matching network.
<ldcd0[m]>
Lmao
<whitequark>
the 100% mode seems very handy for powering stuff from li-ion
<whitequark>
where it reduces frequency until it gets low enough and it just acts as a pass transistor
<whitequark>
that's cool, i didn't know that's a thing
<ldcd0[m]>
Yeah I don't totally understand how they're generating the gate voltage though
<ldcd0[m]>
Like is there some little tiny switched capacitor boost in there?
<whitequark>
probably yeah
<whitequark>
can't see what else
<duskwuff0[m]>
oh wait: maybe it was a backroom deal with precision resistor manufacturers? 😉
<ldcd0[m]>
Vishay-Dale doing monopoly things
<josHua[m]1>
as we all know, glasgow was named in the hopes that it would give a swift kick in the chest to our friends at Future Technology Devices, in Glasgow
<josHua[m]1>
I would say I am proud to announce the results of three evenings of hacking, but I am not really sure if I should take pride in this or not
<josHua[m]1>
do you have serial applications that expect to speak to, say, a FT2232H? do you have Linux applications that speak to a /dev/ttyUSB, but you would rather use them with your, well... Glasgow?
<josHua[m]1>
well, above is an extremely dumb proof of concept that emulates just enough of an FT2232H to actually spit the UART output over a Glasgow
<josHua[m]1>
it does this by, indeed, emulating a FT2232H over USB/IP
<josHua[m]1>
I have not stress tested it in the slightest, but I have opened two instances of picocom, and made them talk to each other. there is a lot of unimplemented stuff, but the general idea is there. try it, you may like it.
scrapbry[m] has joined #glasgow
<scrapbry[m]>
I like the thought that the I in FTDI stands for in
<whitequark>
it's a really cool hack
<whitequark>
the code is also much shorter than i expected
<whitequark>
the most immediate use case for it would be ESP32 bootloader
<whitequark>
i don't know what's worse, usbip or fuse character device
<josHua[m]1>
hm, wait, what has ESP32 got to do with it?
<josHua[m]1>
CUSE definitely is a lot less cross-platform. (there is a path to USBIP on MacOS, at least, even if it is not there today.) and I think the thing I actually wanted out of this was to be able to use my legacy PyFTDI apps with Glasgow and actually emulate MPSSE, which CUSE could not do
<whitequark>
josHua[m]1: ESP32 needs some sideband toggled, RTS or smth
<whitequark>
this is not currently possible with uart pty
<whitequark>
I think maybe it also needs to adjust the baud rate. I'm wondering if you could maybe do this via termios somehow?
<josHua[m]1>
aha
<josHua[m]1>
I have never actually used an esp32
<whitequark>
I've used one maybe once or twice
<whitequark>
the bootloader is like the arduino one on steroids
<whitequark>
RTS just toggles reset iirc?
<whitequark>
it may need both RTS and DTR or something like that, again, don't recall
<whitequark>
this channel would have logs
<josHua[m]1>
ahhh
<josHua[m]1>
(n.b.: zero points if you guess why that sha is pinned in the requirements.txt)
<josHua[m]1>
yeah Id o not blame you for that at all and I was happy to pay the price of downgrading, at least, for now. that machine's running Ubuntu 24.04.3 LTS so I guess it is about time to upgrade to the newest LTS
unlobito has quit [Quit: Quit.]
unlobito has joined #glasgow
<whitequark>
i think i'll probably chill a bit with the forced upgrades from now on because python has merged some really nice things in 3.13 that covers most of the defects we've been stumbling into
<whitequark>
importlib had a really rough track, not having match: was bad too
<whitequark>
oh and the typing improvements were the direct motivation for that upgrade iirc
<whitequark>
i've started sprinkling types around to make the codebase more maintainable now that python types are way more mature
<SnoopJ>
when you say sprinkling, are you relying on type-checking or is it mostly as a means of recording intent?
<whitequark>
both
<whitequark>
i typically write it as a means of recording intent first, and then fix up anything that pylance comes with that i can reasonably fix without making the code read much worse
<whitequark>
glasgow has like thousands of type errors right now, probably half of them due to logging.trace that i worked out how to fix but haven't yet
<SnoopJ>
sounds like the best of both worlds to me, thanks
<whitequark>
it's meaningfully improved the codebase already despite it not type-checking and probably not likely to type-check any time soon
<whitequark>
this used to not be such a clear balance just a few years ago, which is why i adjusted my opinion on python typing
<SnoopJ>
I've been using them for intent (especially aliases) for a while but haven't really taken the plunge on checking those things with a tool yet
<SnoopJ>
I mean in terms of workflow. I've used a bunch of the checkers and helped others sort through typing issues so I'm familiar with the tools, just not really using them for that
<whitequark>
i somewhat underuse aliases
<SnoopJ>
I get the *most* value out of them when I'm working with code that comes to me with its guts hanging out. annotating "what the hell even flows through here" is usually a good first step
<whitequark>
right
cr1901__ has quit [Read error: Connection reset by peer]