I am using the ATSAME70Q21 processor with a Cortex-M7 CPU.
My development environment is Atmel Studio 7. I am using the SAME70 XPlained demo board.
I am creating some code in assembly language.
As a test I setup a vector table at the start of flash (0x00400000) which contain the initial stack pointer value and the location of the Reset_Handler in the first 8 bytes.
When I hit reset on the debugger the Program counter gets set to 0x0040001C (which is correct). The instruction at location 0x0040001C is 0xC046 which is a NOP. The next several instructions in memory are NOPs also.
If I single step the debugger (execute the NOP) the program counter immediately jumps to the HardFault_Handler.
I don't see how executing a NOP can generate a HardFault.
What are likely reasons for a HardFault to occur immediately after reset.
I don't think its a hardware issue since I am using an off the shelf demo board and the problem doesn't occur if I use one of the example C projects in Atmel studio.
Best Answer
Note that assembly language is defined by the tool not the target. For gnu assembler, to date for thumb, particularly with these cortex-ms where you need/want to get the vector table right you started with this problem:
assemble/dissassemble and you can see the problem
(once you know that the vector addresses need to be the address orred with 1)
the minimum but clean solution is to add .thumb_func to indicate that the next label you find is a thumb function not a generic address.
(you have to link not just assemble/disassemble)
and that fixed one vector.
and that fixed the other.
add some C
Then look at the output of the C compiler
(doesnt matter that I defaulted to the arm7, but there is .thumb_func)
some assembly languages will have directives like proc or function or other similar things that you use to declare a label as a function rather than just a generic address to something, so when trying other assemblers for arm you may run into that.
if this uses the gnu assembler then .thumb_func should fix it. I would in your mind think if this as an orring with one not an adding with one in case the address is correct you might end up breaking it with the just add one to everything notion.
Same goes for function pointer stuff in C you have to be careful and can run into this.
not that you are going to run code like that but you can see the problem.
and a fix
what you may very well do is write a bootloader and to get the hop into the loaded code right you need to solve it there are use a function pointer things you can try and maybe not write some asm, but I recommend the asm and orr with one, more likely to get it to work.