search

stm32-rs / stm32h7xx-hal

Peripheral access API for STM32H7 series microcontrollers
BSD Zero Clause License
210 stars 99 forks source link

Expose QSPI control register to switch used bank #449

Closed ElouanPetereau closed 7 months ago

ElouanPetereau commented 10 months ago

Hi, I'm using this library with a STM32 H7 series microcontroller which is connected to a NOR Flash with 2 chips.

Since this NOR Flash support QuadSPI, I wanted to use it but I also want to access to both memory chips.
Since Both of my flash chips are used separatly, one for image backup and one for temporary storage, I want to access to only one of them at a time.
My problem is that, when I looked at the Dual-Flash mode, it seems that I have to read and write to both chips at the same time as from the Quad-SPI interface on STM32 microcontrollers and microprocessors STM documentation, I can read:

Note that all bytes at even addresses are stored in Flash 1 while all bytes at odd addresses are stored in Flash 2. As described in the figure above, in Dual-Flash mode the same command, address and alternate are sent to both Flash 1 and Flash 2.

This is really not ideal for me because I don't want to risk corrupting the backups when doing any operation on the other chip.

On top of that, I only have one clock and one reset GPIO line available for both since the chips have been mounted to use the Dual-Flash mode. This means that I can't create two QSPI peripherals using QUADSPI.bank1() and QUADSPI.bank2() since these functions consume the given pins and thus, the common clock.

This pull request is here to propose a solution for this case and for that I created a new QSPI.bank_switch() method that accept a PinsBank1And2 list of pins to consume and a default bank.
To change the addressed bank, I exposed the QUADSPI control register trhough a change_bank() method.

Also please note that I'm far from being an expert in Flash memories so if you know a solution to my problem that does not require any change in the STM32 hal I will gladly take it.

richardeoin commented 9 months ago

Thank you for the PR! Hopefully me or someone else will take a detailed look at it soon.

The continuous integration checks for nightly Rust are failing, but not because of your changes! So you don't need to fix anything.

ElouanPetereau commented 7 months ago

Hello again,
Do you still plan to merge this PR or is there still something that I can do to improve it?

richardeoin commented 7 months ago

Hi! There was a period when v0.15.0 and v0.15.1 were being released that I avoided merging new changes, but now that's done. Thanks for the rebase!

I concluded that this PR is good to merge as-is, and experimenting with a slightly different way of implementing this (like the QspiSwitchable idea) can happen in another PR. So I'll merge this one now.