As per some document reference that I found on net the expected vector table generated by assembler is give below
__Vectors DCD __initial_sp ; Top of Stack DCD Reset_Handler ; Reset Handler DCD NMI_Handler ; NMI Handler [...more vectors...]
00000000 LDR PC, =__initial_sp 00000004 LDR PC, =Reset_Handler 00000008 LDR PC, =NMI_Handler
but if we see actual code, it will be like
0x00000000 0268 LSLS r0,r5,#9 0x00000002 1000 ASRS r0,r0,#0 0x00000004 0169 LSLS r1,r5,#5 0x00000006 0000 MOVS r0,r0 0x00000008 0171 LSLS r1,r6,#5 0x0000000A 0000 MOVS r0,r0 0x0000000C 0173 LSLS r3,r6,#5 0x0000000E 0000 MOVS r0,r0
Any idea where will be the vector table?
Thanks
The vector table does not contain code - it contains addresses.
Therefore, if you try to interpret it as code, you will get nonsense.
As per ARM manual first instruction that executed after reset is the Init stack pointer and after that it will jump to reset handler that actually an application. But this we cannot see when we debug a project in KIEL ARM. Same way if we see in 8051 project (KEIL PK51) we can clearly see that 0x00 location is jump instruction that jumps to start up code. also same way we can see the other Jump table to other interrupt vectors
Please help to understand
Thanks Mahesh
"As per ARM manual first instruction that executed after reset is the Init stack pointer"
Not quite!
This is not an instruction - it is part of the hardware startup sequence.
A more helpful way to say it might be that the SP (stack pointer) is loaded from the 1st entry in the vector table, then the PC (program counter) is loaded from the 2nd entry, and then the processor runs from there - using that value of the PC to fetch its first instruction.
Again, in ARM, the vector table contains addresses.
The 8051 is quite different! In the 8051, the so-called "vector table" contains instructions
Some might argue that the 8051 does not have a true "Vector" Table...
See: www.8052.com/.../181745.
Link without the dot: www.8052.com/.../181745
What document, exactly?
Always give a link, so that people can check that it's a good document, and/or that you are correctly interpreting what it says.
Beware of just implicitly trusting everything you find on the net - always verify it against "official" documentation!
Please have a look in the below link
infocenter.arm.com/.../index.jsp
here they have clearly mentioned that "The vector table is fixed at address 0x00000000"
So according to that Vector address for the reset is "0x00000004". It essentially means that when controller get reset it start execution from the 0x00000004 from flash. And the first instruction that it will execute the loading a address of the reset handler and jump to actual subroutine.
Please have a look
Regards Mahesh M
That document also clearly states:
"The vector table contains the reset value of the stack pointer, and the start addresses..."
(My emphasis).
OK; that's not just "some doc that I found on the net" - that is actual reference material from ARM themselves!
"here they have clearly mentioned that 'The vector table is fixed at address 0x00000000'"
Indeed they do.
"So according to that Vector address for the reset is '0x00000004'"
Indeed.
"It essentially means that when controller get reset it start execution from the 0x00000004 from flash"
Wrong!
Did you not read my previous post?
For the 3rd time, the Cortex-Mx Vector Table contains addresses - it does not contain instructions!
This is a fundamental difference between the Vector Table on Cortex-Mx (among others) and the so-called "vector table" on the 8051. Again, see: www.8052.com/.../181745
As the ARM document clearly states:
"The vector table contains ... the start addresses"
For a description of how the Vector Table entries are used, see: "Exception entry"
"The processor performs a vector fetch that reads the exception handler start address from the vector table"
Again, it does not fetch an instruction from the Vector Table - it fetches the address of the handler.
As I have worked mostly on 8051 platform , I am getting little difficulty to understand ARM core. Sorry for the trouble but even though I have not clearly understood the difference between the 8051 and ARM vector table.
where can we see the vector table in actual code or How can we register some function in Vector table?
Appreciate some more document if you can suggest for reference
For ARM7 it has Reset Vector too, after Reset, the ARM core fetches the first instruction from address 0x00 (Reset Vector).
It's really quite simple:
On an 8051, the so-called "vector table" contains the (start of) the actual service routine; When an interrupt occurs, the 8051 executes the instruction that it finds in the appropriate vector table entry.
On an ARM (and many other architectures; including x86), the vector table contains the start address of the service routine; When an interrupt occurs, the ARM fetches the address that it finds in the appropriate vector table entry, and then executes the instruction located at that address.
"where can we see the vector table in actual code"
Again, the ARM Vector table is not "actual code"; it is just a list of addresses - and (apart from the 1st entry) each of those addresses is the start address of the handler.
"How can we register some function in Vector table"
In 'C', the name of a function gives its address.
"Appreciate some more document if you can suggest for reference"
It is such a fundamental part of operation of any embedded system that any examples will have to have a Vector Table!
Have you looked at the examples that Keil provide?
Have you looked at the examples that the chip manufacturer provides?
Book list available here: http://www.keil.com/books/
Some training providers, seminars, etc, listed here: http://www.keil.com/events/ http://www.keil.com/events/links.asp http://www.keil.com/events/classlist.asp http://www.keil.com/events/seminarlist.asp
Originally, I thought that the OP is migrating from ARM7 to Cortex-M0; so I wrote that.
Note that one of the significant differences between ARM7 and Cortex-Mx is in the interrupt handling - including the vectors.
ARM7 Vectors: infocenter.arm.com/.../index.jsp
Thanks Andy Now I am clear in concept
:)