<adamgreig-m>
It depends on that bit but it also depends on the divider setting
<thalesfragoso[m]>
oh, it changes depending on the ppre
<thalesfragoso[m]>
yeah, got it, the naming confused me a bit :)
<adamgreig-m>
On the other stm32s it only depends on the divider setting iirc
<adamgreig-m>
So this is like a bonus go faster bit perhaps
<thalesfragoso[m]>
yes, usually it's x1 if not divided, and x2 if divided
<adamgreig-m>
And here the same unless you set this bit and then it doubles (so long as it's divided enough to be ok)
<thalesfragoso[m]>
yeah, it has to be divided to more than 4 to do x4
<thalesfragoso[m]>
more or equal*
yruama_lairba[m] has joined ##stm32-rs
<firefrommoonligh>
Oh shit. I switched to L412 instead of 432 and 443 due to shortages. Turns out 412 has a subtly different RTC. They all have the same RM, but there are 2 separate RTC sections!
<firefrommoonligh>
And the PAC is incompat with the former
<firefrommoonligh>
Things like the CR reg being in different addresses makes this messy
<firefrommoonligh>
I think I acn make things work by changing the address of CR and nothing else. How would you approach this?
<firefrommoonligh>
For a specific use case, ie doesn't need to be a general solution
<firefrommoonligh>
Just need to make it so `regs.cr` points to a diff hex address offset
<firefrommoonligh>
the other changes are mainly related to tamper and alarms
<firefrommoonligh>
Maybe I could fork the PAC from the nightly repo, put it in as a git dep, make the change in there somehow, and leave the crates.io one commented out so I can switch back dependign on mcu availability?
<firefrommoonligh>
Note that the PAC distinguies based on L4x1 etc, so it isn't able to make this distinction the way it's set up
<dirbaio[m]>
so even within L4 there are incompatible RTCs? wow
<firefrommoonligh>
L41x and L42x use one RTC variant, and L43x, L44x etc use a differnet
<firefrommoonligh>
pac uses the latter
<dirbaio[m]>
why 🤣
<firefrommoonligh>
and distinguishes as L4x1, L4x2 etc, so there's no way to specify
<firefrommoonligh>
No idea! The only diff are where they put the tamper and alarm events, and if it can auto clear the wakeup interrupt, and some of the reg addressing!
<firefrommoonligh>
They have whole different RM RTC sections!
<firefrommoonligh>
in the same manual!
<firefrommoonligh>
I discovered this after having no signs of life from the RTC after switching chip
<henrik_alser[m]>
<dirbaio[m] "why 🤣"> Because having them be the same would make too much sense
<firefrommoonligh>
How do I fork a PAC?
<adamgreig-m>
if it's a simple change maybe PR it to stm32-rs?
<adamgreig-m>
you can then use the nightly build from git immediately after the change is merged
<adamgreig-m>
(and if you click fork on the nightly repo, your fork of it won't be changed automatically, so you can depend on that in your builds until it's released)
<firefrommoonligh>
Some notes. One of them has ICSR, and the other has ISR. Both same address. ISR has many more fields. Most of those fields are on CR on 41x etc
<firefrommoonligh>
Some regs are basically the same, but at diff addresses (including CR, which is critical. CALR, SSR, the alarm regs too are all at diff addresses)
<firefrommoonligh>
Some of the alarm and tamper functionality might be different. 41x etc can auto clear the wakeup flags
<firefrommoonligh>
Those are the highlights
<firefrommoonligh>
I could make my project work just by changing the CR address
<dirbaio[m]>
wtf -_-
<firefrommoonligh>
Thanks for the pointout on the .yaml files - I'll star there
<firefrommoonligh>
Other than that, this MCU is p much the same as the other L4s I've worked with, other than having smaller RAM and flash, and coming in 32pin QFNs
<firefrommoonligh>
The RTC is teh weird part
<firefrommoonligh>
My code (using L4x2 PAC) was compiling, but evidently writing to bogus RTC registers, and the RTC was completely nonfunctional
<firefrommoonligh>
I don't see anything relevant in those `yamls, nor in the `common_patches/rtc` files they poitn to
<adamgreig-m>
I haven't had time to investigate the specifics this evening but might be able to have a look tomorrow, but the first place to check is the svd file (or the generated stuff at https://stm32-rs.github.io/stm32-rs/) to see if there's any hint of the second RTC peripheral in any device you could copy from
<adamgreig-m>
or maybe it's defined in some other L4 or other family device, even, in which case it's easy to copy it
<firefrommoonligh>
And could also change it for the other 5 modules, as well as the alarm, ssr, calr addresses too, but to properly fix this, I'm not sure how to tackle those SVDs at this time
<firefrommoonligh>
Hmm... Looks like that line is just for the docs. Any idea where you'd find the actual address for a reg offset?
<dirbaio[m]>
it's defined by the offset in the struct
<dirbaio[m]>
all regs are 4 bytes. reg in the 3rd position is at offset 4*2=8
<firefrommoonligh>
Which file and line would I edit?
<firefrommoonligh>
* Which file should I edit? Sorry; I'm woefully inept at this.
<dirbaio[m]>
that one you linked
<dirbaio[m]>
you need to reorder fields so each is at the right offset
<firefrommoonligh>
Ooohhhhhhhhhh
<firefrommoonligh>
That makes sense!
<firefrommoonligh>
Thanks bros adamgreig
<firefrommoonligh>
* Thanks bros adamgreig and dirbaio Works using the nightlies. I don't think I'm up to patching the SVDs at this point. Not sure how to open them yet