<SbastiendHerbais>
I did however confirm that it knows about this address range using probe-rs chip info and it does show it correctly
<SbastiendHerbais>
After changing some more things, I do see reference in the logs of the algo, and I added my own tracing::info call to print out the algorithm and it chooses the right one, however it still doesn't work with the same error as I had mentioned previously
<danielb[m]>
might be worth trying to change ap to 0. not sure why the pack contains ap: 1, but the reference manual has 0x00: AP0 - Cortex-M7 debug access port
<danielb[m]>
* might be worth trying to change ap to 0 in core_access_options. not sure why the pack contains ap: 1, but the reference manual has 0x00: AP0 - Cortex-M7 debug access port
<dirbaio[m]>
that's working in embassy HIL tho
<dirbaio[m]>
or did it get changed 0->1 in the pack updates?
<danielb[m]>
no I don't think it did
<danielb[m]>
but 1 has a very cryptic explanation of "D3" next to it which is not the core 🤷♂️
<dirbaio[m]>
😵💫
<danielb[m]>
your h7s3 might have some slightly different behaviour 🤷♂️
<dirbaio[m]>
¯\_(ツ)_/¯
<danielb[m]>
i guess an st-link firmware update would also be worth a try
<danielb[m]>
hm I guess `probe-rs info` is useful at this point as it scans through the APs, Dherse run that and paste its output somewhere, please
<SbastiendHerbais>
danielb: you're welcome, thank you for helping me!
<SbastiendHerbais>
Ok, I did try a known-good firmware from STM32CubeIDE but flashed using probe-rs and it runs no problem. So clearly there's something wrong with my rust project too... At least with the changes I made, I can flash firmware now 🎉
<SbastiendHerbais>
Ok, a bit of a dumb question, but why can't I load from GDB using probe-rs gdb? I can debug which is awesome (almost there), and is there of way of both: launching it with the RTT monitor (probe-rs run) and with a GDB server (probe-rs gdb)?
ryan-summers[m] has joined #rust-embedded
<ryan-summers[m]>
<SbastiendHerbais> "Ok, a bit of a dumb question..." <- Because the `load` command is not implemented. Loading is done via `probe-rs flash` instead
<ryan-summers[m]>
If you want to load the file into gdb, just use the file command instead
<MathiasKoch[m]>
Essentially i have a number of json structures of varying complexity, that I would like to be able to load and store in either EKV or sequential storage, in such a way the each leaf field (primitive types) becomes its own key-value entry. Would that be suitable for miniconf?
<MathiasKoch[m]>
* key-value entry in a flattened way. Would
<ryan-summers[m]>
Yup. The path is configurable too via types, so you could use JSON style paths like .foo.bar or whatever you like. It uses a generic Key trait
<ryan-summers[m]>
So it's literally a key-value lookup for structs using serde. All the values are [u8] slices
<MathiasKoch[m]>
Thats cool! I'll take a look, and get back if i have any questions :p
<MathiasKoch[m]>
Much better than having to reinvent the full wheel :)
<ryan-summers[m]>
Yeah it took us a long time to refine it properly. The docs are a bit rough right now because its a complex problem. Been meaning to clean them up and write a blog post on it for a while since I think miniconf is super useful
<ryan-summers[m]>
But feel free to ping me if you have Qs, and that'll help me figure out how to reorg any of the docs too
<SbastiendHerbais>
ryan-summers: that makes a lot of sense, thanks!
<MathiasKoch[m]>
Thanks!
<SbastiendHerbais>
OMG finally, I managed to run custom rust code on it from the OSPI flash! Apparently the examples from the embassy repo don't work on this model as it's the configuration of the core (RCC etc.) that was wrong and causing it to be in a bugged(?) state... Need to figure out what parameters work now
<dirbaio[m]>
<SbastiendHerbais> "OMG finally, I managed to run..." <- what board and chip do you have?
<SbastiendHerbais>
STM32H7S78-DK board with an STM32H7S7L8H6HU. I am re-implementing embassy_stm32::init myself to see which is the part that it doesn't like (proceeding via elimination)
<dirbaio[m]>
it's probably the SMPS
<JamesMunns[m]>
Very likely, the RCC setup assumes it is in the "reset state" when you call ::init, and by setting up RCC (and maybe other peripherals) for OSPI access, it is getting confused, or hanging because it is making in incorrect state transfer
<JamesMunns[m]>
(that being said, defer to Dirbaio's knowledge over my guess 😅)
<dirbaio[m]>
ah right it could be that too
<JamesMunns[m]>
s/in/an/
<SbastiendHerbais>
It's likely something like that indeed, hence why I'm trying to process via elimination since I don't know any better, but since embassy_stm32::init doesn't let me configure whether to do that or not, I guess I'll have to do it manually (for now)
<JamesMunns[m]>
I wonder if an unsafe init_with_assumed_rcc(...) method would be a good idea, at least to start
<SbastiendHerbais>
Indeed, in my case the RCC is handled by the "bootloader"
<SbastiendHerbais>
* the "bootloader" from ST
<JamesMunns[m]>
like, you have to manually give all the current RCC settings, which will initialize the various states/globals, then proceed from there. Not sure if that is reasonable tho
subtlename has joined #rust-embedded
subtlename has quit [Changing host]
subtlename has joined #rust-embedded
<dirbaio[m]>
there is some defense against RCC being already initialized
<JamesMunns[m]>
or at least, maybe change some clocks that could cause Fun and Unexpected Behavior?
<SbastiendHerbais>
James Munns: would be a pretty big problem indeed 😅
<JamesMunns[m]>
yeah, I don't remember offhand how much embassy resets, but if it touches any "load bearing" clocks or peripherals, that could be bad lol
<dirbaio[m]>
syscfg is just random junk bits though
<SbastiendHerbais>
That does cause me some headache, since I can't init time_driver as it is private in embassy_stm32
<SbastiendHerbais>
so I am sort of stuck either way
<dirbaio[m]>
i'd recommend you change embassy-stm32 to a path dep and edit it directly
<SbastiendHerbais>
I can turn the LED on then the programs waits forever for a timer that isn't even enabled 😂
<dirbaio[m]>
then when you find what's wrong we can fix it upstream
<dirbaio[m]>
if you change that line to do enable_with_cs (not reset), does it worK?
<JamesMunns[m]>
(this is the reasoning behind my unsafe "set with the current state without actually changing any hw settings" suggestion)
<dirbaio[m]>
one solution is the "assume init" you mention, which skips doing init
<dirbaio[m]>
the other solution is to make init more robust against hw already being inited
<dirbaio[m]>
there's no fundamnetal reason you can't just init everything again
<JamesMunns[m]>
that makes sense to me! I don't know how reasonable/desirable that is, but it certainly would be better UX
<JamesMunns[m]>
dirbaio[m]: you'd have to be *really* careful not to cut off any XIP type stuff, for one
<dirbaio[m]>
the only exception is multicore, that you do need the 2nd core to assume_init because the 1st one is already running
<dirbaio[m]>
but for single-core, the bootloader is not running anymore
<dirbaio[m]>
so we can just reinit everything however we like
<JamesMunns[m]>
CC diondokter, who I think is currently poking around multicore things and might have opinions or like to be informed here :D
<dirbaio[m]>
currently init doesn't cut off qspi/ospi/xspi, it leaves it alone
<dirbaio[m]>
it will change rcc config, that can break xspi if it makes it go too fast
<dirbaio[m]>
so you'd have to check how is the BL configured the xspi and make sure your rcc config is compatible with that
<M9names[m]>
could you also build up your config based on the current state, rather than assuming the initial state?
<M9names[m]>
i assume this would be practically impossible beyond 1-2 layers deep in the clock tree but at least core clock + direct decendents?
<JamesMunns[m]>
something like "check if the desired state is the current state, if so, just skip"?
<M9names[m]>
that would be simpler
<JamesMunns[m]>
and then I wonder about peripherals being in non-reset state, or shared peripherals for multicore? But that's kind of all spooky anyway?
<dirbaio[m]>
M9names[m]: > <@9names:matrix.org> could you also build up your config based on the current state, rather than assuming the initial state?
<dirbaio[m]>
> i assume this would be practically impossible beyond 1-2 layers deep in the clock tree but at least core clock + direct decendents?
<dirbaio[m]>
yeah that's possible too, but it's more code. you'd need code both for "config struct -> registers" and "registers -> config struct". And separate out the code for "config struct -> frequencies". Currently it's a single big function that does "config struct -> registers, frequencies"
<dirbaio[m]>
also if the config struct comes from registers, the compiler can't const-propagate anything, so it'd have worse code size
<MathiasKoch[m]>
ryan-summers: Hmm, am I doing something wrong, or is it not possible to use `get/set_json` functions on the root (the entire object)?
<ryan-summers[m]>
Isn't that just serializing with serde-json-core?
<MathiasKoch[m]>
Ehmm, might be yeah :p makes sense
<ryan-summers[m]>
But in general, miniconf defines the data structure as a tree, composed of internal and leaf nodes. You can only get/set on leaf nodes, not on entire subtrees based from some internal node outward
<ryan-summers[m]>
Could probably add that functionality if needed though
<ryan-summers[m]>
* needed though, but might make trait bounds around ser/de complicated
<MathiasKoch[m]>
Makes sense 👍️ I can make due with the leaf nodes
<ryan-summers[m]>
You can define an entire complex json structure as a leaf node, something like {"foo": 1, "bar": {"baz": "a"}} can be an entire leaf node, but then you couldn't set bar.baz on its own, itd have to be done atomically with foo and bar
<SbastiendHerbais>
<dirbaio[m]> "if you change that line to do ..." <- Which line? 🤔
<dirbaio[m]>
how're you checking this? adding logs at every line?
<dirbaio[m]>
or removing the lines?
<SbastiendHerbais>
Early return; out of the function
<SbastiendHerbais>
can't log in there for some reason
<dirbaio[m]>
it should work if you enable the defmt feature
<dirbaio[m]>
* it should work if you enable the defmt feature in embassy-stm32
<JamesMunns[m]>
SbastiendHerbais: this is because probe-rs does a polling-based attach of RTT, the init is so fast after boot you crash before probe-rs has time to attach
<SbastiendHerbais>
JamesMunns[m]: That's what I figured as well, but since I can just early return I figured I wouldn't need to do anything fancy to wait for RTT to be ready
<SbastiendHerbais>
I am just being selectively lazy 😄
<JamesMunns[m]>
you could also do a huge cortex_m::asm::nop to give RTT enough time to init, something like 100ms
<SbastiendHerbais>
That's the bootloader's exact clock tree/config
<SbastiendHerbais>
I don't see either why changing to HSI breaks things since it's already in HSI
<SbastiendHerbais>
Well no, the SYSCLK uses the PLLCLK as a source
<SbastiendHerbais>
which is at 600 MHz not 64
<dirbaio[m]>
yea... so changing sysclk 600->64 should make everything after it like 10x slower
<dirbaio[m]>
which should be fine ...? 🤷
<SbastiendHerbais>
Yes, doing the change in the IOC file and it doesn't complain that anything is "too slow" or whathever
<dirbaio[m]>
what's xSPI clocked from?
<SbastiendHerbais>
Could it also be changing the pre-scale of the HSI for some reason? Since it doesn't seem to like (in the GUI right) when changing that?
<SbastiendHerbais>
Lemme check
<SbastiendHerbais>
Reading the datasheet's diagram: I have no idea, it's HCLK5 or ACLK or PLL2_S_CK or PLL2_T_CK????
<SbastiendHerbais>
If I place it post HSI initialization (inside of init) then it "works"
<SbastiendHerbais>
and by works I mean it says nothing but also does nothing
<dirbaio[m]>
lol
<SbastiendHerbais>
This board really doesn't want to boot 😠
<dirbaio[m]>
well if you violate clock constraints things can crash in fun unpredictable ways
<dirbaio[m]>
I wouldn't read much into it
<dirbaio[m]>
like, getting the error is not necessarily better or worse than getting just a hang
<dirbaio[m]>
IIUC to not violate clocks we should switch xspi before switching sysclk..
<dirbaio[m]>
to not violate the "bus clock must be faster than xspi clock" thing
<SbastiendHerbais>
I think it's fair to say that skipping clock (re-)configuration would be preferable in the end?
<dirbaio[m]>
hmhmhmhm
<dirbaio[m]>
I dunno 🥲
<dirbaio[m]>
it could be. config.rcc.assume_init = true;, then it won't do any rcc register writes but still calculate the freqs based on the settings you've set
<dirbaio[m]>
then it's on you to pass the exact same config that the bootloader set, otherwise frequencies might be wrong (e.g uart or spi going too slow/fast)
<SbastiendHerbais>
That seems like the most reasonable case, to be fair this is a bit of an edge case and I wouldn't necessarily expect embassy to take that into account
<dirbaio[m]>
well this is a recurring problem
<dirbaio[m]>
so it does need some fix
<dirbaio[m]>
also multicore is a similar issue
<SbastiendHerbais>
I was gonna use an STM32H747 initially but multicore just seemed like too much of a pain tbh
<dirbaio[m]>
the old h7's also have many fun DMA gotchas that h7rs doesn't have
<dirbaio[m]>
h7rs is not a bad option
<dirbaio[m]>
if only we can get to boot it lol
<dirbaio[m]>
* if only we can get it to boot lol
<SbastiendHerbais>
I am also hoping to be able to write a nice slint backend for the onboard "GPU" to get some nice GUIs going on
<SbastiendHerbais>
🎉 🎉 IT BLINKS 🎉 🎉
<SbastiendHerbais>
At the wrong speed
<SbastiendHerbais>
but IT BLINKS
<SbastiendHerbais>
🎉
<SbastiendHerbais>
Sorry, I am getting overly excited 😂
<dirbaio[m]>
🥳
<dirbaio[m]>
what was it
<SbastiendHerbais>
I'll end up writing a tutorial somewhere otherwise in six months I'll have forgotten how I got this thing to work 😂
<SbastiendHerbais>
Quick question: which one in the IOC is the timer prescaler?
<SbastiendHerbais>
I guess it's the /3 before the "To TIPU"?
<dirbaio[m]>
> the timer
<dirbaio[m]>
there's many many timers
<dirbaio[m]>
which one do you want? the one used for embassy-time?
<SbastiendHerbais>
I mean it's called Rcc::timer_prescaler :-p
<SbastiendHerbais>
yes
<dirbaio[m]>
timer_prescaler is the "X2" at the top right, in "to APBx timers"
<SbastiendHerbais>
Ok nice, thanks!
<dirbaio[m]>
then that clock goes to the actual TIMx
<dirbaio[m]>
and the TIMx itself has another divider
<SbastiendHerbais>
It blinks at the right speed now
<SbastiendHerbais>
Thank you so much for all the help
<SbastiendHerbais>
:D
<dirbaio[m]>
what's the list of things you changed?
<dirbaio[m]>
i'd like to get it working, to add an example for using external flash to the repo
<dirbaio[m]>
(well if you want to do that and send a pull request that'd be even more awesome)
<SbastiendHerbais>
lots of if !config.assume_init and this condition, I'll push on a fork so that you can take a look, I don't mind opening a PR either if you'd like that, but likely tomorrow/Wednesday
<dirbaio[m]>
ah you did the actual assume_init thing
<SbastiendHerbais>
yep
<dirbaio[m]>
okay
<SbastiendHerbais>
Mind you I also have a modified probe-rs *
<SbastiendHerbais>
External main mem, as initialized by the bootloader also works, so dirbaio my hats off to you, you're amazing :D
<SbastiendHerbais>
Do you have a GH sponsor button?
subtlename has joined #rust-embedded
subtlename has quit [Changing host]
subtlename has joined #rust-embedded
subtlename has quit [Ping timeout: 276 seconds]
<SbastiendHerbais>
dirbaio: How would I report issues in stm32-data-generated/stm32-metapac? I found that it doesn't implement traits it should (for Ethernet)
<dirbaio[m]>
<SbastiendHerbais> "Do you have a GH sponsor button?" <- not currently, no
<dirbaio[m]>
<SbastiendHerbais> "dirbaio: How would I report..." <- in the stm32-data repo
<dirbaio[m]>
that's the source
<SbastiendHerbais>
Yeah that's what I did, basically it's missing all ETH mode pins
<JamesMunns[m]>
so, how do we get dirbaio hired to ST, just to fix their internal data sources and data stability guarantees, just to quit 3 months later?