2
\$\begingroup\$

I am trying to understand the ARM cortex-M hardware behavior on reset; particularly how the SP and PC values are written upon a cold start or hard reset.

A quick search did find a few similar questions that provides some answers: e.g. https://stackoverflow.com/questions/44832159/arm-cortex-m4-boot-sequence.

Basically, it would seem the hardware (aka PE as referred to by the Arm v7 Architecture Reference Manual) is doing this. The first word of the vector table at 0x0 is taken for SP initialization and the next word gives the address of the reset vector which is loaded to the PC, and a branch to that address is performed to run whatever the reset vector does to continue the booting process. However I'm curious how this is achieved by the hardware.

From the Arm v7-M Architecture Ref Manual, Section "B1.5.5 Reset Behavior" describes actions taken upon reset through a pseudocode (truncated here just to focus on the actions specific to the question):

// TakeReset()
// ============
TakeReset()
   ..
   ..
   ..
   bits(32) vectortable = VTOR<31:7>:'0000000';
   SP_main = MemA_with_priv[vectortable, 4, AccType_VECTABLE] AND 0xFFFFFFFC<31:0>;
   SP_process = ((bits(30) UNKNOWN):'00');
   LR = 0xFFFFFFFF<31:0>; /* preset to an illegal exception return value */
   tmp = MemA_with_priv[vectortable+4, 4, AccType_VECTABLE];
   ...
   ...
   BranchTo(tmp AND 0xFFFFFFFE<31:0>); /* address of reset service routine */

Ignoring the rest of the actions (setting all registers to their reset defaults) how are the actions of setting SP_main and the BranchTo() to reset service routine actually performed? I know this may be 'implementation defined' but what could they be:

  1. Are they hardcoded instructions somewhere in the on-chip ROM area so that the PC upon reset has the address of the instruction to read address 0x0 and load the SP and then load the PC and jump to the reset routine? (In addition to rest of the actions given in the TakeReset() pseudocode)
  2. Is there hardwired logic to do these two initial steps such that these steps are being done before the processor begins it's fetch and execute phase. It would seem more efficient for the reset state of PE to be tied to the appropriate instructions, rather than having additional logic to perform these actions.
\$\endgroup\$
4
  • \$\begingroup\$ ‘On chip rom area’ assuming the chip in question has this, then, yes, it would be reasonable to startup from it. As the Arm doc says - it is ‘implementation dependent’ as in up to the chip designer to decide. It might boot from internal rom , internal flash, internal ram, external ram, external flash. If the arm doc says it does those two initial steps, then that is what it does. The boot memory purely needs to behave like memory and the startup sequence is defined by the Arm core so it makes sense it performs it. \$\endgroup\$
    – Kartman
    Commented Apr 23 at 8:37
  • \$\begingroup\$ How do you think will hard-coded instructions execute without the PC initialized with the address of these instructions? You are just "shifting" the same action to another indirection with this idea. \$\endgroup\$ Commented Apr 24 at 5:39
  • \$\begingroup\$ can't the PC be made to have the reset value of the address of those instructions? Isn't that how some processors start? (not the cortex-M though). In theory, maybe the PC can be set to a reset address that results in always run the system ROM bootloader that carries out the reset sequence using instructions from that memory location. \$\endgroup\$
    – NeedToKnow
    Commented Apr 25 at 2:32
  • \$\begingroup\$ I can see though how it may be simpler instead to have a state machine to do this in hardware as you mention below in your answer \$\endgroup\$
    – NeedToKnow
    Commented Apr 25 at 2:35

3 Answers 3

2
\$\begingroup\$

Some Cortex-M based microcontrollers have a masked programmed ROM as well as user programmable flash.

E.g. from the TI TM4C1294NCPDT datasheet:

enter image description here

Where in the memory map:

  • The Flash starts at address 0x00000000, which contains the vector table defined by the default VTOR Vector Table Offset Register defined in the Arm v7-M Architecture Ref Manual.
  • The on-chip ROM starts at address 0x01000000

Section 5.2.2.2 Boot Configuration of the datasheet contains:

After Power-On-Reset (POR) and device initialization occurs, the hardware loads the stack pointer from either flash or ROM based on the presence of an application in flash and the state of the EN bit in the BOOTCFG register. If the flash address 0x0000.0004 contains an erased word (value 0xFFFF.FFFF) or the EN bit is of the BOOTCFG register is clear, the stack pointer and reset vector pointer are loaded from ROM at address 0x0100.0000 and 0x0100.0004, respectively. The boot loader executes and configures the available boot slave interfaces and waits for an external memory to load its software.

If the check of the Flash at address 0x0000.0004 contains a valid reset vector value and the BOOTCFG register does not indicate the boot loader, the boot sequence causes the stack pointer/reset vector fetch from Flash. This application stack pointer and reset vector is loaded and the processor executes the application directly.

Which shows that device specific logic can control the reset sequence. For the above TI example device that allows a brand new device from the manufacturer, which contains erased flash, to run a boot loader in the masked programmed ROM which can then program the user flash by retrieving the program from an external communication interface.

There is also Arm Cortex-M on FPGA which is described as Evaluate or commercially deploy FPGA devices with Arm CPUs with no license fees or royalties. Cortex-M3 and Cortex-M1 CPUs are seamlessly integrated as soft CPUs on FPGAs from multiple partners. Perhaps that ARM IP could be also used to learn how the reset behavior can be customised.

\$\endgroup\$
1
  • \$\begingroup\$ Would it be a reasonable assumption that the cortex-m interrupt handling hardware logic (context saving and restoring) carries out the reset sequence too ending in a jump to the reset vector address? \$\endgroup\$
    – NeedToKnow
    Commented Apr 25 at 2:28
0
\$\begingroup\$

These operations are implemented using hardware logic, and to understand it requires some basic knowledge of digital circuitry, such as how the 74LS374 chip stores the logic values on the external pins to internal registers, while the initial assignment of the SP and PC on the arm is similar to the hardware operation.

\$\endgroup\$
0
\$\begingroup\$

I'm pretty sure that there is only hardware involved, for example as a simple and small state machine.

You might call this "microcode" or "instructions," but it cannot be a piece of code containing native ARM instructions. If it were, the CPU needs again some logic to initialize its PC to point to this piece of code. This is in general the same action as directly loading the reset vector into the PC. A design would not waste silicon for such instructions, if it can get away with less for a state machine.

All other initialization of registers most probably works like any initialization of (clocked) digital logic: via asynchronous reset.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.