documentation of reset behavior ?

[geoffreymbrown]

Posted on January 16, 2012 at 18:35

The cortex-M3 specification has the reset vector at 0x0000004.  The stm32 places it in flash at 0x08000004, but requires modifying the vector table offset as part of the startup code. 

PM0056 says this: The Program Counter (PC) is register R15. It contains the current program address. Bit[0] is always 0 because instruction fetches must be halfword aligned. On reset, the processor loads the PC with the value of the reset vector, which is at address 0x00000004. I found this in RM00041 (section 2.4 -- Boot configuration) Boot from main Flash memory: the main Flash memory is aliased in the boot memory space (0x0000 0000), but still accessible from its original memory space (0x800 0000). In other words, the Flash memory contents can be accessed starting from address 0x0000 0000 or 0x800 0000. Is that the whole story, or is there some other documentation ?  Does the aliasing persist or is just at startup ? Geoffrey

[Tesla DeLorean]

Posted on January 16, 2012 at 20:45

The memory aliased/shadowed at zero is controlled by the BOOTx pins at startup, and on the STM32F1 series this cannot be changed, so it never changes. Changing the vector address isn't that important, unless you have multiple code images in FLASH (ie boot loader and application). If the application code is at 0x08004000 you would want to remap the vector there. The addresses you store in the vector(s) usually reflects the natural address of the memory being used, but that would depend on the compiler/linker and the base address begin used.

The PC is always loaded with an ODD address to reflect that it is to run 16-bit Thumb code. I think this is reflected if you copy it out to a register. This bit is assumed to be zero for the purposes of reading the memory, and the address at which the instruction physically resides. For the most part you can ignore this and let the compiler/linker handle it, it will become important if you want to jump to an absolute/immediate address.

[geoffreymbrown]

Posted on January 16, 2012 at 21:39

I think I'm close to a complete answer.  The mapping from 0x08000000 to 0x000000000 is persistent based upon the value of the boot pins at reset ?  This is one of those areas where the documentation is a little thin.

Geoffrey

[Tesla DeLorean]

Posted on January 16, 2012 at 22:10

Yes, the state of the BOOTx pins is latched at RESET, and when exiting STANDBY

The values on the BOOT pins are latched on the 4th rising edge of SYSCLK after a reset. It is up to the application to set the BOOT1 and BOOT0 pins after reset to select the required boot mode. The BOOT pins are also resampled when exiting the Standby mode. Consequently, they must be kept in the required boot mode configuration in the Standby mode. After this startup delay has elapsed, the CPU fetches the top-of-stack value from address 0x0000 0000, then starts code execution from the boot memory starting from 0x0000 0004