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> Afaik, cselr is only L4?
<dirbaio[m]1> I should track dmamux there too
<dirbaio[m]1> :S
NEYi has quit [Quit: Leaving]
oaky has quit [Ping timeout: 240 seconds]
<firefrommoonligh> Not showing it on L5, which is also listed there as dma1+
<firefrommoonligh> L5 uses mux
<firefrommoonligh> F3 is no mux, no csel. L4 is no mux, with csel. G0, G4, L5 use mux. H7 and f4 have a completely diff layout
<firefrommoonligh> L5 has some security stuff too, but it's a transparent add on
<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
<firefrommoonligh> Thanks - that sounds important