STM32H755 stalling CPU when erasing bank 1 flash from code running in bank 2 (but not the other way around)

[mark03]

I am implementing a firmware-update mechanism on STM32H755 (Nucleo board, MCU rev U) in which the two flash banks are independent.  New firmware is flashed by erasing the "other" bank (which is always mapped at 0x0810 0000 and accessed with the ____2 register set, e.g. FLASH_CR2), then writing the candidate firmware image into that bank, verifying a SHA hash after programming, and finally toggling the SWAP_BANK bit in option bytes, performing an option-byte update, and software reset to boot into the new image.  This works, and I can perform one update after another, ping-ponging back and forth between the banks.  Note that the running application is always mapped at 0x0800 0000, is [much] less than 1 MByte, and never touches the other bank at 0x0810 0000 except to erase and program it when an update is requested.

The issue I am having is that when the code runs in Bank 2 and an update commences, the bank erase of Bank 1 is stalling the CPU for several seconds.  The same thing does *not* happen when the code is running in Bank 1 and performs a bank erase on Bank 2.  Also, the actual programming never stalls the CPU---only the initial bank erase, and only when it is Bank 1 being erased.

AFAICT, there is no difference at all between these two scenarios---everything should be identical between them, down to the contents of every single register and memory location, *except* for the SWAP_BANK bit in the option bytes.  So why would one behave differently?  (Note, for this test, I am updating with an identical firmware image, so there is no difference pre- and post-update.)

I was able to find corroborating evidence of this unexpected behavior in another forum post, here:

https://community.st.com/t5/stm32-mcus-products/bus-stall-when-writing-erasing-flash-on-stm32h7/td-p/360606 

(Note the OP is not describing it---it's later in the thread, user @MDrew.1 , and they apparently never got to the bottom of it.)

I know better than to claim a silicon bug :)  although I cannot think of another explanation.  Can you?  Best-case scenario, someone has figured out an undocumented way around this problem.

Why does this matter?  Well, I'd like to use a watchdog timer, and 4+ seconds is a pretty long watchdog expiration.  Also, other RTOS tasks are supposed to be running in the background during the update process, and they do, just fine---when the code is running in Bank 1.

[mƎALLEm]

Hello,

You did accept the solution in this thread: STM32H755 failing to erase bank 1 while running from bank 2 (opposite works fine) , do you mean you didn't solve your issue? If yes, better to continue the discussion.

[mark03]

The other thread was about a separate misunderstanding I had about the ____1 registers versus the ____2 registers in the FLASH block; I didn't realize that swapping the banks also swaps the register sets, so that the ____2 registers *always* relate to whichever bank is mapped at 0x0810 0000.  The issue I'm seeing now is different, hence the new thread.  I've posted my updated code in case that clarifies the question.

[mark03]

I don't think code is going to explain better than I already have above, but in case someone asks, here is the code which erases the inactive flash bank.  The CPU stall happens at the first write to FLASH_CR2 (setting the BER and START bits), and lasts about four seconds.  Afterwards, the code resumes and everything works as expected.  (The actual flash writes do not stall the CPU.)  And again, the stall doesn't happen at all if we are running in Bank 1 and staging a new image in Bank 2, only when running in Bank 2 and staging the new image in Bank 1.

// Bank-erase the inactive flash (always BANK2, i.e. the bank mapped at 0x08100000)
if (FLASH->CR2 & FLASH_CR_LOCK)
{
 FLASH->KEYR2 = 0x45670123;
 FLASH->KEYR2 = 0xcdef89ab;
}

FLASH->CR2 |= (FLASH_CR_BER | FLASH_CR_START); // start erase of inactive bank
while (FLASH->SR2 & FLASH_SR_QW)
{ vTaskDelay(pdMS_TO_TICKS(100)); } // yield to other tasks while we wait

FLASH->CR2 |= FLASH_CR_PG; // enable programming on this bank

// programming flash at 0x0810 0000 happens here (not shown)

// New image hash checked out; swap banks, update option bytes, and reset
if (FLASH->OPTCR & FLASH_OPTCR_OPTLOCK)
{
 FLASH->OPTKEYR = 0x08192a3b;
 FLASH->OPTKEYR = 0x4c5d6e7f;
}

FLASH->OPTSR_PRG ^= FLASH_OPTSR_SWAP_BANK_OPT; // toggle the SWAP_BANK_OPT bit
FLASH->OPTCR |= FLASH_OPTCR_OPTSTART; // start option-byte write
while (FLASH->OPTSR_CUR & FLASH_OPTSR_OPT_BUSY) // wait for it to complete
{ vTaskDelay(pdMS_TO_TICKS(100)); }

SCB->AIRCR = (0x5fa << SCB_AIRCR_VECTKEY_Pos) | SCB_AIRCR_SYSRESETREQ_Msk;

[waclawek.jan]

VTOR is set how?

JW

[mark03]

VTOR does not need to be changed because the interrupt vectors are in the same place as usual, 0x0800 0000, regardless of which bank is mapped there.  An updated firmware image contains everything that the original image contains, including the interrupt vectors and the code which performs firmware updates.  (In this scheme, there is no separate bootloader.)

[waclawek.jan]

After reset, VTOR points to 0, not to 0x0800 0000.

I'm not sure what's the mechanism which makes it to point elsewhere, so maybe it's worth to check if it's not interrupt code execution which actually stalls the processor during FLASH bank erasure.

JW

[mark03]

@mƎALLEm and other ST employees monitoring the forum, this seems like it wouldn't be too difficult to reproduce.  Could one of you try that?  If so, I think this should be raised as a possible silicon errata.  I'm happy to experiment on my end first if you have any [well reasoned and supported] suggestions for things to try.

[mark03]

I'm happy to report that I found the root cause of the bus stall.  And it's not what I hypothesized above.

@mƎALLEm was on the right track, except the issue was not speculative access at all.  (It would be surprising for the CPU to speculatively access system memory, out of the blue, unless something else was reading nearby addresses.)  No, the issue was intentional access...

My ADC driver was reading the VREFINT calibration data at 0x1ff1e860, which I forgot is technically part of Bank 1 flash.  It seems odd that a region you can't erase, and can't program, can nevertheless block a flash erase operation in that bank.  Presumably there is a hardware reason for this?  I fell into the trap of thinking of it as a separate ROM area, disconnected from flash.

Setting up the MPU to block system-memory accesses quickly gave me a MemManage fault, which allowed a quick pinpoint of the problem code.  In my project this is easy to resolve by storing the cal data once during initialization instead of accessing it repeatedly.

[waclawek.jan]

@mark03,

thanks for coming back with the solution. Nice catch, and far from being straightforward!

While the 'H7 DS+RM clearly place these "constants" into one of the FLASH banks, some other families (I've checked the mid-range 'L4) don't, but as the "constants" are surely factory-programmed into the system-portion of FLASH, they are likely to constitute some of the banks (and probably Bank1), too. I wonder, what percentage of the dozens of unresolved threads reporting similar problems on this forum throughout the years could be traced to this very issue...

JW