> What’s New ? <

Flash Controller

Port New Mcu

Irc channel 27-0802003 discussion, crest is advising leStoppe re porting a new MCU, the PY32F030 to Mecrisp-Stellaris. The problem is the PY32F030 flash controller.

<crest_> leStoppe: even armv6m (m0, m0+) supports the 32 bit branch and link instruction for reasonable far calls, but it's not enough to cover the distance between flash and sram on most chips
<crest_> in that case a PC releative load + branch (and link) to register is problably the shortest and fastest way for far calls/jumps
<crest_> tp,leStoppe it depends on the flash controller, some can't be programmed while running code from them, some support at least writing to one of its banks while executing from an other
<crest_> some even allow read-while-erase from different sectors of the same bank
<crest_> you have to look up the restrictions of your chip and its flash controller
<crest_> an other common problem especially in better chips are ecc protection bits for wide flash words e.g. 256 bit (32 byte) have to be programmed at once on a stm32h7xx because that's the granularity of the ecc protection
<leStoppe> crest_, the RM of this chip says the following :
<leStoppe> During a program and erase operations to the Flash memory, any attempt to read the Flash memory will stall
<leStoppe> the bus. The read operation will proceed correctly once the program and erase operations has completed. This
<leStoppe> means that code or data fetches cannot be made while programming and erasing operations are in progress.
<crest_> which chip?
<leStoppe> py32f030
<crest_> stalling isn't failing
<crest_> the instruction fetch unit would stop making progress while the programming happens
<leStoppe> crest_, right now what I observe is that half the time it writes correctly but the rest of the time, mecrisp-stellaris thinks that the memory isn't empty or 4 byte aligned
<crest_> but if the flash programming operation completes the cpu should continue running
<leStoppe> when this happens, if I try to reflash after a reset, it may work again
<leStoppe> it's like there's some instability
<crest_> the most universal reliable solution is to keep (a copy of) the flash programming function in sram
<leStoppe> I'm attempting that. Trying to modify the loader to put the flash programming subroutine in ram
<leStoppe> trying to figure out a way to init the ram area from flash right now
<crest_> the rp2040-ra port does this with the whole kernel and flash dictionary
<crest_> because of the slow flash, but large (by m0+ standards) sram
<leStoppe> that seems to be a trend with the chips that have large sram
<leStoppe> loading from a big fat external spi flash
<crest_> sram is fast and affordable enough, but requires power to retain information