jacobrosenthal[m has quit [Quit: Idle for 30+ days]
oaky has joined ##stm32-rs
oaky has quit [Quit: Leaving]
NEYi has joined ##stm32-rs
oaky has joined ##stm32-rs
<firefrommoonligh>
More DMA quirks - L4 and F3, on the v1 periph use a channel selection register to multiplex, while L5 and g4, also on v1 and mostly with the same registers and steps, use a separate DMAMUX block
<firefrommoonligh>
They don't have a periph-to-channrl mapping table - it might be customizable
<dirbaio[m]1>
oh so that's what CSELR was for
<dirbaio[m]1>
...fun
<dirbaio[m]1>
so there are four variants?
<dirbaio[m]1>
v1, v1+cselr, v1+dmamux, v2 ?
<firefrommoonligh>
3
<firefrommoonligh>
That I've found
<firefrommoonligh>
Oh wait you're saying there's a v1 without cselr and without DMAMUX?
<firefrommoonligh>
I'm not clear how DMAMUX works. Cselr is straightfwd; pick the channel listed in the mapping table. Set the cselr to the row of the periph in that table.
<firefrommoonligh>
Mix has a much longer table with mux inputs going up to ~50
<firefrommoonligh>
As in, I don't know how to choose a channel for a given periph from that
<firefrommoonligh>
Is v1 without either for F1 etc?
<dirbaio[m]1>
I think yes
<firefrommoonligh>
Btw, other than this channel selection stuff, f3, g4, g0, and l5 are p much the same from a software perspective
<firefrommoonligh>
DVD quirks aside, and the newer ones having 8 channels vice 7, and the m33 secure channel
<dirbaio[m]1>
also H7 is DMAv2 but also has dmamux?!?!
<firefrommoonligh>
Lol
<dirbaio[m]1>
so FIVE variants?
<firefrommoonligh>
The only part of this that's tough is v1 and v2 needing very diff code
<firefrommoonligh>
The rest is a bandaid
<firefrommoonligh>
* SVD quirks aside, and the newer ones having 8 channels vice 7, and the m33 secure channel
<dirbaio[m]1>
oh and there's BDMA too
<firefrommoonligh>
Ehat
<firefrommoonligh>
* What
<firefrommoonligh>
* Btw, other than this channel selection stuff, f3, g4, g0, l4 and l5 are p much the same from a software perspective
<firefrommoonligh>
Ok, so f3 doesn't have mux or cselr
<firefrommoonligh>
So does it just auto know which mapping row to use? While on L4 you have to use the correct cselr?
<firefrommoonligh>
Look at ccr1 linked there. Full of fields. The others are blank
<dirbaio[m]1>
oh yeah that's bugged.. also ccr2 has NDT which is not in CCR1, is that a mistake too?
<firefrommoonligh>
Should I post an issue on stm32 GH?
<dirbaio[m]1>
I guess, yup
<dirbaio[m]1>
who uses L5 anyway? the crazy trustzone stuff is practically not supported
<dirbaio[m]1>
with rust
<dirbaio[m]1>
there's not even a hal :D
<firefrommoonligh>
I disagree with there not being a HAL!
<dirbaio[m]1>
yours :)
<firefrommoonligh>
I'm going to use it for my next battery powered project or current ones, once it becomes more availy
<firefrommoonligh>
I would be already if it weren't for the shortage
<dirbaio[m]1>
but none before yours right? so you're the first one :D
<firefrommoonligh>
It appears so
<firefrommoonligh>
For the most part, the trust zone is an add-on
<dirbaio[m]1>
why pick the L5? just curious
<firefrommoonligh>
The main periphs I've seen it interacts with are Flash and DMA
<firefrommoonligh>
Probably more I haven't looked at
<dirbaio[m]1>
hm interesting
<dirbaio[m]1>
these chips boot in secure mode by default
<dirbaio[m]1>
in nrf53/nrf91 there's stuff in the peripherals that doesn't work exactly the same in secure vs non-secure mode
<firefrommoonligh>
It's the latest good-performance STM with low-power features
<dirbaio[m]1>
and stuff that doesn't work at all, like the nrf91 modem
<dirbaio[m]1>
so you have to properly initialize trustzone stuff and switch to non-secure mode
<firefrommoonligh>
Granted, most/any? STM can work sufficiently well with low power using stop and standby
<dirbaio[m]1>
you can't ignore it and pretend it's a normal chip :(
<firefrommoonligh>
Sure you can
<dirbaio[m]1>
not in nrf's, that's why I'm warning you =D
<firefrommoonligh>
Ah gotcha
<dirbaio[m]1>
stm32l5 might be different, if you're sure about that feel free to ignore me
<firefrommoonligh>
L5 uses dual modes, eg for flash the regs are split into secure and non secure variants
<dirbaio[m]1>
I don't get trustzone anyway
<dirbaio[m]1>
everything you can do with it you can do with the "classic" MPU
<dirbaio[m]1>
seems like overengineering from ARM so they can charge more $$ for fancier designs BeCAuSE sECuRiTY
<dirbaio[m]1>
it'd be a shame if your chip wasn't secure would it? 😏
<firefrommoonligh>
Good catch on ndt! That's a sep register. You can see it correctly one level up in the docs
<firefrommoonligh>
I don't either
<firefrommoonligh>
Could be capitalizing on trendy Iot, or something beyond use cases I've considered
<firefrommoonligh>
I plan on ignoring it, even if I use m33 chips
<dirbaio[m]1>
if you can ignore it you're very lucky
<dirbaio[m]1>
nrf's trustzone is full of WTFs
<firefrommoonligh>
I haven't used an L5, and am going off of RMs. You think it'll get on the way!
<firefrommoonligh>
* I haven't used an L5, and am going off of RMs. You think it'll get on the way?
<dirbaio[m]1>
No ide
<dirbaio[m]1>
* No idea
<firefrommoonligh>
Also it's surprising stm32W doesn't use it
<dirbaio[m]1>
check for gotchas like peripehrals that can only do non-secure DMA accesses
<dirbaio[m]1>
if all ram is secure and the peripheral only does non-secure accesses, you can't use it
<dirbaio[m]1>
that's the case with the modem in nrf91
<firefrommoonligh>
Posted GH issue. Thank you
<firefrommoonligh>
Good to know; I've been considering nrf for future Bluetooth projects
<dirbaio[m]1>
nrf52s are great, and no trustzone bullshit
<dirbaio[m]1>
nrf53 is wayyyy overkill. trustzone, multicore 🤣
<gdamjan[m]1>
i guess trustzone is if you link together multiple proprietary blobs from different vendors, and you want your stuff apart from their memory view
oaky has joined ##stm32-rs
oaky has quit [Quit: Leaving]
mtthwmeyer[m] has joined ##stm32-rs
jacobrosenthal[m has joined ##stm32-rs
<firefrommoonligh>
Has anyone here used DMAMUX?
<ryan-summers[m]>
Yeah, pretty extensively in the STM32H7 hal
<ryan-summers[m]>
Never used any of the advanced trigger mechanics in it though
<firefrommoonligh>
Thanks
<firefrommoonligh>
Between skimming that HAL, and a SO post of someone with my same question, I should be able to figure it out
<firefrommoonligh>
(IMO it's not obvious at all how you choose the right channel from the RM, compared to non-mux variants)
<firefrommoonligh>
* (IMO it's not clear how you choose the right channel from the RM, compared to non-mux variants)
<firefrommoonligh>
It appears the key part is setting DMAMUX_CR's DMAREQ_ID field IOC the table
<firefrommoonligh>
Bottom line: without mux, you find the hard-set channel in a table, and pass that when configuring the channel. With mux, you pick a channel (with some restrictions), and set DMAREQ_ID in the CR reg for the channel to the periph's input number in a table
<ryan-summers[m]>
The MUX just makes it so you can map (essentially) any DMA request to any DMA channel. Beware that you shouldn't ever map one request to multiple channels
<ryan-summers[m]>
Or you can get weird racy behavior
<ryan-summers[m]>
* Or you can get weird race-y behavior