EdgeTX
feat: bootloader support for SPI NOR flash storage
This PR add support to initialize SPI NOR flash in horus and nv14 targets:
- Add storage initialization function in bootloader
- Add placeholders for user to select the use of SPI NOR flash instead of SD card for storage
I have added TX16S support. Need to change the commented lines in CMakelist.txt and hal.h to test it out.
I think Raphael still thinking how to make use of internal NOR flash together with SD card. Need to enable the support of multiple volume of FatFS to really make use of it. This PR just enable the exploration of usage by adding something in BL to init the NOR flash volume for feature explorarion.
Just like the flashing firmware, it need a long press [Enter] to erase.
Just like the flashing firmware, it need a long press [Enter] to erase.
No. The sequence is currently Erase Flash Storage => Erase Flash Storage (Hold [ENT] long to erase) => "This may take up to 200s" => 10 minutes later, short press of ENT... several seconds later returns to main screen, flash has been erased. The short press of ENT should not have been needed for the erase to actually happen ;)
This behavior should be the same as PL18, I never need the short press [Enter], after wait should just return.
I'll have to check on the PL18EV, but I bet you do... not sure this is right? Looks like it is halting until ENTER release when in the ST_CLEAR_FLASH phase... for all SPI_FLASH enabled targets ;)
https://github.com/EdgeTX/edgetx/blob/cf32dbbed40da88bbb381354cb061b043c02a6e8/radio/src/targets/common/arm/stm32/bootloader/boot.cpp#L534-L535
I'll have to check on the PL18EV, but I bet you do... not sure this is right? Looks like it is halting until ENTER release when in the
ST_CLEAR_FLASHphase... for allSPI_FLASHenabled targets ;)https://github.com/EdgeTX/edgetx/blob/cf32dbbed40da88bbb381354cb061b043c02a6e8/radio/src/targets/common/arm/stm32/bootloader/boot.cpp#L534-L535
This should be common to all targets.
I just verified on PL18EV that this same behaviour was happening. It did not happen on 2.10 bootloader, however, so most likely stemmed from one of the key handing change PRs... with those lines removed it works as expected.