2024-04-17 07:29 AM
Heyho,
I'm currently working on an ethernet bootloader, I have it all working now.
File upload via browser using http POST, into HyperRAM (~200 ms for 400kB bin file),
from HyperRAM to external SPI flash (for now octal on H735-Discovery, later changed to quad on custom board),
then upon command writing internal application flash sectors from SPI flash.
Jumping back and forth also works.
I was curious how long all the operations take, using the SysTick - no problems for all operations, except when internal flash was erased or programmed...
At first I was looking for bugs in my code, then it occurred to me, that flash access might be "limited" when modifying it... ouch. :D
I found this thread, confirming my suspicions:
Although it makes absolutely sense, but where can I find this info in the H73x RM0468 ?
2024-04-17 08:05 AM
Read accesses to the active Flash array will stall the processor, basically it will stuff wait-states to hold off the MCU until the array has finished.
Can be avoided by executing from RAM, or from an entirely different bank of FLASH.
Must avoid interupts/vectors pointing into FLASH, and any call tree for any function you call/use.
Not sure this is explicitly discussed in any given manual, assumed it was common knowledge for most every NOR Flash for the last several decades. You basically have to spin wait on the FLASH's status. On the STM32 the safety fence is stalling the MCU, which only kicks in when you try to peer around the curtain.
2024-04-17 08:17 AM - edited 2024-04-17 08:18 AM
Hello,
I was curious how long all the operations take, using the SysTick - no problems for all operations, except when internal flash was erased or programmed...
Maybe you need to relocate the vector table and the code in the RAM while doing this operation.
Although it makes absolutely sense, but where can I find this info in the H73x RM0468 ?
There is no read-while-write operation support on H723 like in H743:
H743 (RM0433) :
2024-04-17 08:34 AM - edited 2024-04-17 08:35 AM
Is there any important advantage to move bootloader code to RAM?
Everything is running smoothly now, so I probably won't touch it as it is now.
What I need is absolute reliability of the bootloader.