Call targetConfiguration() once before config is loaded and again afterwards in case the config needs to be changed to load from SD card etc
Drop SPI clock during binding
Remove debug
Add per device SPI DMA enable
Fix sdioPinConfigure() declaration warning
Reduce clock speed during SPI RX initialisation
* Enable QSPI flash chip drivers on NUCLEOH743 for some CI visibility.
* Rework QSPI flash detection.
* Supports chips that are in QSPI mode by default (factory).
* Supports chips that are in QSPI mode due to configuration (e.g. Quad
Enable in Non-Volatile on W25Q128FV)
* Supports chips that need 8 dummy bytes (e.g. W25Q128JV) and ones that
don't (e.g. W25N01G)
Flash operations can specify how long to wait before the next operation
is issued.
Prior to this the amount of time waited, and when, was wrong.
e.g.
m25p16_eraseCompletely - possibly waits ages TO START, starts, exit.
m25p16_pageProgramContinue - waits DEFAULT_TIMEOUT_MILLIS to START,
starts, exits.
m25p16_pageProgramContinue would fail to write to the flash as the
device was still busy erasing and didn't wait long enough.
what happens now is:
m25p16_eraseCompletely - waits using the current timeout, starts, sets
timeout to be `now + BULK_ERASE_TIMEOUT_MILLIS`, exits.
m25p16_pageProgramContinue - waits using the current
`BULK_ERASE_TIMEOUT_MILLIS`, starts, exists, sets timeout to be `now +
DEFAULT_TIMEOUT_MILLIS`.
Since the timeout is stored in the flashDevice_t the solution also works
for multi-die devices which use an instance of flashDevice_t for each
die.
If there is only a single partition, its type is FLASHFS, and it uses the entire geometry, then perform a full rather than a sector-based erase.
The full erase is significantly faster than erasing by individual sectors.
- Update flash w25n01g driver to support QuadSPI.
- flash_m25p16 update for QuadSPI support
- w25m driver update for QuadSPI support
- Use 100Mhz (ULTRAFAST) clock for QuadSPI w25n01
- Conditionalize QUADSPI code in w25n01g driver
- Use handle instead of handle_u
