RSS

ARM registers

What are the different ARM register ?

ARM has totally 16 general purpose register. They are R0-R15.

Registers R0 through R7 are the same across all CPU modes; they are never banked.

R13 and R14 are banked across all privileged CPU modes except system mode. That is, each mode that can be entered because of an exception has its own R13 and R14. These registers generally contain the stack pointer and the return address from function calls, respectively.

Aliases:

  • R13 is also referred to as SP, the Stack Pointer.
  • R14 is also referred to as LR, the Link Register.
  • R15 is also referred to as PC, the Program Counter.
Registers across CPU modes
usr sys svc abt und irq fiq
R0
R1
R2
R3
R4
R5
R6
R7
R8 R8_fiq
R9 R9_fiq
R10 R10_fiq
R11 R11_fiq
R12 R12_fiq
R13 R13_svc R13_abt R13_und R13_irq R13_fiq
R14 R14_svc R14_abt R14_und R14_irq R14_fiq
R15
CPSR
SPSR_svc SPSR_abt SPSR_und SPSR_irq SPSR_fiq
 
Leave a comment

Posted by on 16/02/2014 in ARM

 

User and System modes change in ARM

ARM mode change can happen only in privileged mode, but in case of a system call handling while the ARM is in user mode (which is a non-privileged mode), how does the ARM mode change?

In the case of system calls on ARM, normally the system call causes a SWI instruction to be executed. Anytime the processor executes a SWI (software interrupt) instruction, it goes into SVC mode, which is privileged, and jumps to the SWI exception handler. The SWI handler then looks at the cause of the interrupt (embedded in the instruction) and then does whatever the OS programmer decided it should do. The other exceptions – reset, undefined instruction, prefetch abort, data abort, interrupt, and fast interrupt – all also cause the processor to enter privileged modes.

 
Leave a comment

Posted by on 29/10/2013 in ARM

 

Why are the return addresses of prefetch abort and data abort different in ARM exceptions?

Why are the return addresses of prefetch abort and data abort different in ARM exceptions?

These offsets are due to the processor’s pipelining and the fetch/decode/execute stages.

The processor’s program counter (PC) is updated at specific points during execution. Exceptions can occur during different phases of fetching/decoding/execution.

In the case of the prefetch abort, the instruction cannot be (has not been) executed; the exception occurs only when the processor actually attempts to execute the instruction (some prefetched instructions may not be executed).

In the case of the data abort, the instruction is being executed, and the instruction’s execution causes the exception.

From the ARM documentation:

Regarding prefetch abort:

[The prefetch abort exception] Occurs when the processor attempts to execute an instruction that has prefetched from an illegal address, that is, an address that the memory management subsystem has determined is inaccessible to the processor in its current mode.

… Instructions already in the pipeline continue to execute until the invalid instruction is reached, at which point a prefetch abort is generated.

… because the program counter is not updated at the time the prefetch abort is issued, lr_ABT points to the instruction following the one that caused the exception. The handler must return to lr_ABT – 4

And regarding the data abort:

[The Data Abort exception] Occurs when a data transfer instruction attempts to load or store data at an illegal address.

When a load or store instruction tries to access memory, the program counter has been updated. A stored value of (pc – 4) in lr_ABT points to the second instruction beyond the address where the exception was generated. When the MMU has loaded the appropriate address into physical memory, the handler should return to the original, aborted instruction so that a second attempt can be made to execute it. The return address is therefore two words (eight bytes) less than that in lr_ABT

So in other words, for the data abort, the handler must return to lr_ABT – 8 (two words/instructions previous)

 
Leave a comment

Posted by on 29/10/2013 in ARM

 

How to Enable/Disable ARM FIQ/IRQ?

Does anyone know how to enable/Disable ARM FIQ/IRQ?

Other than enabling or disabling the IRQ/FIQ while you’re in supervisor mode, there’s no special setup you should have to do on the ARM to use it, unless the system (that the ARM chip is running in) has disabled it in hardware (based on your comment, this is not the case since you’re seeing the FIQ input pin driven correctly).

For those unaware of the acronyms, FIQ is simply the last interrupt vector in the list which means it’s not limited to a branch instruction as the other interrupts are. That means it can execute faster than the other IRQ handlers.

Normal IRQs are limited to a branch instruction since they have to ensure their code fits into a single word. FIQ, because it won’t overwrite any other IRQ vectors, can just run the code directly without a branch instruction (hence the “fast”).

The FIQ input line is just a way for external elements to kick the ARM chip into FIQ mode and start executing the correct exception. There’s nothing on the ARM itself which prevents that from happening except the CPSR.

To enable FIQ in supervisor mode:

MRS r1, cpsr ; get the cpsr.
BIC r1, r1, #0x40 ; enable FIQ (ORR to disable).
MSR cpsr_c, r1 ; copy it back, control field bit update.

To enable IRQ in supervisor mode :

MRS r1, cpsr ; get the cpsr.
BIC r1, r1, #0x80 ; enable IRQ (ORR to disable).
MSR cpsr_c, r1 ; copy it back, control field bit update.

Note:

The postfix _c identifies that bit-fields being updated is the control field bits[7:0] of cpsr.

To disable FIQ/IRQ in supervisor mode : just replace BIC instruction with ORR(Logical OR).

To disable FIQ in supervisor mode:

MRS r1, cpsr ; get the cpsr.
ORR r1, r1, #0x40 ; disable FIQ (ORR to disable).
MSR cpsr_c, r1 ; copy it back, control field bit update.

To disable IRQ in supervisor mode :

MRS r1, cpsr ; get the cpsr.
ORR r1, r1, #0x80 ; disable IRQ (ORR to disable).
MSR cpsr_c, r1 ; copy it back, control field bit update.

 
Leave a comment

Posted by on 29/10/2013 in ARM

 

How does ARM7 pipelining works(3 Stage Pipeline)

How does ARM7 pipelining works

One of the key features of the fast performance of ARM microcontrollers is Pipelining. ARM7 Core has three-stage pipeline that increase instruction flow through processor up to three times. So each instruction is executed in three stages:

  • Fetch – instruction is fetched from memory and placed in pipeline;
  • Decode – instruction is decoded and data-path signals prepared for next cycle;
  • Execute – instruction from prepared data-path reads from registry bank, shifts operand to ALU and writes generated result to dominant register.

ARm Pipeline

Pipe-lining is implemented in hardware level. Pipeline is linear, what means that in simple data processing processor executes one instruction in single clock cycle while individual instruction takes three clock cycles. But when program structure has branches then pipeline faces difficulties, because it cannot predict which command will be next. In this case pipeline flushes and has to be refilled what means execution speed drops to 1 instruction per 3 clock cycles. But it isn’t true actually. ARM instructions has nice feature that allow to smooth performance of small branches in code that assures optimal performance. This is achieved in hardware level where PC (Program Counter) is calculated 8 bytes ahead of current instruction.

 
Leave a comment

Posted by on 25/10/2013 in ARM

 

ARM Boot sequence

In this post, we deal with start-up code of ARM.This may not be the best tutorial , these details are also available through various ARM resources (such as arm-info-center) , however for the sake of completion of our discussion ,here is – the flow the startup code for an  ARM based embedded system.

Step 1: The reset

On startup, the processor will jump to fixed location ,(most ARM cores support two vector locations 0x0 or 0xFFFF0000, controlled via a signal sampled at reset and a bit in CP15. Lets say that the core is configured to have its vectors at 0x0 ). This address should contain the reset vector and the default vector table. Reset vector is always the first instruction to be executed.The reset vector in this table will contain a branch to an address which will contain the reset code. Normally, at this stage, the rest of the vector table contains just the dummy handler- a branch instruction that causes an infinite loop(this is because this vector table is used very briefly and later on replaced by vector table in RAM after memory remap operation-explained in step 3) .

 Step 2: The reset code

This reset code to which the jump has been executed from the reset vector will do the following tasks:

  • Set up system registers  and memory environment
  • Set up MMU
  • Setup stack pointers : initialize stack pointers for all ARM modes
  • Set up bss section : zeroing the ZI data region,  copying initialization values for initialized variables from ROM to RAM
  • Set up hw : CPU clock initialization , external bus interface configuration,low level peripheral initialization etc

Step 3: Remap Memory

One of the job of the initial reset code will be memory remapping.At the time of power up, the processor jumps at fixed location 0x0.So, this is important to ensure there is some executable code present at this location at the time of power up. And to ensure this, some non volatile memory should be mapped to this address.

So, at the time of power up, ROM is mapped to 0×0 location which contains the reset exception and default vector table. However, later on, during the s/w execution, on every interrupt, the processor needs to jump to the vector table which starts from 0×0 location. If this vector table is located in ROM, the execution of interrupts will become very slow as ROM is slower than RAM (ROM requires more wait states as well as more power consumption for access as compared to RAM).Also, if the vector table is present in ROM, it cannot be modified by code.

Therefore for faster and more efficient execution of interrupts , it is better if interrupt handlers and vector table is located in RAM at address 0×0.However, if RAM was mapped to address 0×0 at the power on of processor, being a volatile memory , it won’t contain any executable code. Thus, it becomes important that at the time of start up, ROM is located at 0×0 address and then during normal execution RAM is re-mapped to this location.Memory remapping can be achieved through hardware remapping, that is changing the address map of the bus. This can also be acheived through MMU.

Step 4: Jumping to C code (main function for eg)

After the execution environment has been setup (setting up the vector table (handlers for each entry in the vector table), stack, critical I/Os etc., copying initialization values for initialized variables from ROM to RAM and resetting all other variables to zero.), assembly code can give way to C Code.

Step 5: Setting up the external memory, loading and executing the OS image

External memory should be setup before loading an image to it (Refresh rate, clock etc),OS image can then be loaded from flash(assuming its NAND flash) to RAM.The OS image may be compressed in which case it needs to be decompressed before PC can be modified to point to the operating system entry point address.

References :

(You can also refer them as “good” ARM study material for development)

  1. ARM Developer’s Suite Developer Guide
  2. Building Bare-metal ARM systems with GNU
  3. ARM System Developer’s guide(Andrew N.Sloss,Dominic Symes,Chris Wright)
 
Leave a comment

Posted by on 18/10/2013 in ARM

 

!! Welcome !! (will be updated soon !Stay Tuned)

Welcome to ARM questionnaire Blog.®

This site brings you basic knowledge/fundamentals about arm and its architecture.

This site will be updated soon with some more questions, please reply with feedback/comment (if any).

 
Leave a comment

Posted by on 17/10/2013 in ARM