# ARM Cortex behavior on erased flash

After erasing the flash of a typical microcontroller with an ARM Cortex, I assume the flash contents to be all ff.

What is the behavior of the microcontroller after reset, especially that of its processor, in this case?

The only things I am reasonably certain about are these: Upon reset, the inital PC and the initial SP are set to 0xffffffff.

I am unsure what happens next: Is there an exception because the stack pointer is unaligned? Does the processor fetch an instruction from memory address 0xffffffff? If the instruction is fetched, is it taken from the two bytes (I think it should be a Thumb instruction because the initial PC has the low bit set) at 0xffffffff and 0x00000000 or does the instruction fetch access wrap around the "System" section boundary from 0xffffffff to 0xe0100000?

• Note that built-in ROM might check these values to be valid (for example NXP chips have a checksum for first few vectors) and just not transfer control to application code. – domen Apr 3 '19 at 8:26
• I think that this check is a very sensible idea. Some parts - I am specifically thinking of the STM32F4 line - do not seem to have this check but start to execute the "application" in the flash right away. – distributed Apr 3 '19 at 8:53

## 1 Answer

The core will enter LOCKUP state. This failure is actually architecturally defined (v7M):

Vector read error at reset, when reading initial PC or SP value Behavior Lockup at priority -1.Lockup address 0xFFFFFFFE

The core will then remain stuck in this state (since it is impossible to fetch from an XN region):

In most cases, when the processor enters Lockup state, it remains in that state until a reset, such as from a watchdog.

This is in contrast to some of the other lockup states where the error can technically be cleared and the core will just keep trying forever.

I think that the SP being illegal is benign until the stack is used.