edadson001[m] has joined ##stm32-rs
<DerFetzer[m]> Can someone point me in the right direction on how to jump to the L4's DFU bootloader from software? I am having a board where the boot button is not accessible anymore when the housing is closed.
<adamgreig-m> DerFetzer: I've not tried on L4, but the general approach is to set a flag in ram, reset the mcu, then at boot check that flag, and if it's set, you clear it and then jump to the bootloader address using cortex_m::asm::bootload
<adamgreig-m> ST's app note on their DFU bootloader, and the reference manual, should say what the address is for the system memory
<adamgreig-m> the reason to set a flag and reboot and so forth is because the bootloader generally needs the whole system to be in a reset state
<adamgreig-m> I have an example here for F0 https://github.com/adamgreig/ffp/blob/master/firmware/src/hal/bootload.rs but it hasn't been updated to use the new cortex_m::asm::bootload which simplifies it a lot
<DerFetzer[m]> Ahh thank you very much! the bootload method looks perfect! I've already read the bootloader manual but was not sure how to do the register stuff.
Sijmen has quit [Quit: Idle for 30+ days]
<firefrommoonligh> Hi. For SPI DMA, do you need to keep SPI disabled while not doing the transfers? The RMs imply this by saying "Enable the SPI" and "Disable the SPI" in the "when starting communication" and "to close communication" "mandatory" steps in order
<dirbaio[m]1> I think it's OK, ie you can keep it enabled if you're going to start another DMA
<thalesfragoso[m]> Maybe an overrun when the fifo (?) gets full and dma doesn't drain them
<thalesfragoso[m]> But in that case I would probably swap 2 and 1
<firefrommoonligh> Hmm...
<firefrommoonligh> From what you said and the RM, it sounds like the reasoning is that if the data buffer (FIFO?) is still doing things while you enter a low power mode, surprising (bad) things could happen
<firefrommoonligh> I can't get DMA working, so at this point I'm trying to comply to the RM as strictly as possible
<firefrommoonligh> And there's a weird contrast: DMA is generally considered the way to go where available, but the examples I've found in HALs etc don't use it
<firefrommoonligh> It looks like `stm32f1xx` HAL has something though, so comparing my code to that
<firefrommoonligh> * It looks like `stm32f1xx` HAL has a module and example, so I'm comparing my code to that
<firefrommoonligh> * It looks like `stm32f1xx` HAL has a SPI DMA module and example, so I'm comparing my code to that
<dirbaio[m]1> with DMA you can read `DMA_SxNDTR` while the transfer is ongoing to check how many bytes have been transferred
<dirbaio[m]1> is it guaranteed that these transferred bytes are already written to RAM?
<dirbaio[m]1> ie if during a transfer of 256 bytes, read NDTR and get 200, it means buf[..56] is guaranteed to be valid?
<dirbaio[m]1> or the bytes can still be "in flight" somehow?
<dirbaio[m]1> (without stopping DMA)
<dirbaio[m]1> writing from stm32f4 to pc through the nucleo's stlinkv1 cdc uart
<dirbaio[m]1> * writing from stm32f4 to pc through the nucleo's stlinkv2 cdc uart
<dirbaio[m]1> also happens if i'm writing just a single line, and also happens without DMA
<dirbaio[m]1> is the stlink uart known to be crap?
<thalesfragoso[m]> <dirbaio[m]1 "ie if during a transfer of 256 b"> Good question, iirc it says to wait the enable bit to go down after writing 0 to it...
<dirbaio[m]1> yeah, but that's if you want to stop it
<thalesfragoso[m]> But that doesn't answer your question , yeah
<dirbaio[m]1> q is if I don't want to stop it, just read whatever's been transfered
<dirbaio[m]1> if it's the amount of "really transferred" bytes it'll be awesome for BufferedUart
<thalesfragoso[m]> I would expect it to decrement the N after transfering to RAM, but...
<thalesfragoso[m]> I don't remember seeing something about it on the manual
<dirbaio[m]1> no need to stop and restart to "flush" it, unlike in nRF's
<dirbaio[m]1> yea manual says nothing :S
<dirbaio[m]1> this does seem to suggest it's decremented after
<dirbaio[m]1> but is it done really after the data is fully stored? there's no write buffering?
<dirbaio[m]1> or write buffering is only a thing for CPU cores (?)
<thalesfragoso[m]> You have burst in some DMAs, but I think it would decrement just after
<thalesfragoso[m]> That part of the manual seems to indicate you're fine
<dirbaio[m]1> and does the core have caches for RAM? haven't seen any I think
<dirbaio[m]1> hopefully there's no cache you have to flush lol
<thalesfragoso[m]> M4, no M7 yes
<dirbaio[m]1> aaaaa
<thalesfragoso[m]> DMB :)
<dirbaio[m]1> and it's "local" to the core? ie a dma write won't write to the cache?
<thalesfragoso[m]> Yeah, that was the problem with the ethernet DMA on the F7
<dirbaio[m]1> DMB doesn't flush caches does it? only write buffers
<thalesfragoso[m]> Not cache, but write buffer
<thalesfragoso[m]> Cache only affects some RAMs and you have to enable them
<dirbaio[m]1> huh
<dirbaio[m]1> H7 is nighmare lol
<thalesfragoso[m]> On stm32-eth we just say to not place the buffers on cacheable RAM
<thalesfragoso[m]> F7 also has a M7
<dirbaio[m]1> oh boi
<thalesfragoso[m]> Usually people just cache TCM, most DMAs can't even access TCM
<firefrommoonligh> Does anyone know what this step means under DMA SPI instructions for F4? `// 2. Enable DMA streams for Tx and Rx in DMA registers, if the streams are used.`?
<firefrommoonligh> * Does anyone know what this step means under DMA SPI instructions for F4? `2. Enable DMA streams for Tx and Rx in DMA registers, if the streams are used.`?