bootloaders "reset memory mapping"
TL;DR?  skip to the short answer at the bottom.

This appears to be a cortex-m based microcontroller.  Which means you need the datasheet and other reference materials from Atmel/Microchip.  In that documentation it will state cortex-mX -m3 -m4 -m7 -m0 -m0+ one of those, so you go to arms website and get the technical reference manual for that core. In that document you will find the architecture version either armv6-m or armv7-m, either one of those has your answer.

The vector table for a cortex-m is a table of 32 bit values, the first value at offset 0x0000 from VTOR (resets to 0x00000000) is a value you wish to have placed in the stack pointer register.  The value at offset 0x004 is the reset vector the address to the code you wish to run after a chip reset, orred with one.  so if your reset handler is at address 0x100 then you need 0x101 in this location, you do not supply the orr one, you get the tools to do it.  And so on there are a dozen or so core handlers, data abort, prefetch, undefined instruction and such not necessarily in that order.  Then the individual interrupts, unlike the older full sized arms with one IRQ line and one FIQ line the cortex-m design has up to 256 individual interrupts, but it depends in part on the core and the chip designers (Atmel in this case or whomever they hired if outsourced) as to how many of those are actually hooked up.  For all of these vectors from reset to the last of the interrupts the vector table contains a 32 bit address orred with one that is the offset to the vector table offset register.  some of the cores you cannot change the vector offset and it is fixed at 0x00000000.  

The vector table offset in the CORE resets to address 0x00000000 and after a core reset (assume chip reset) two things happen the 32 bit value at address 0x00000000 relative to the core is read and placed in the stack pointer, the 32 bit value at address 0x00000004 relative to the core is read, lsbit checked for a one, then that lsbit is stripped (0x101 becomes 0x100 for example) and execution starts there.  Reset is a special exception obviously, other exceptions and interrupts simply take the address at the appropriate place in the table, save state to the stack (a bunch of registers and other values) and start execution at that address with the lsbit stripped off..

Now on the chip side of things the chip vendor uses that/those busses to connect to flash, ram and peripherals.  Unlike the full sized arms they are not as free AFAIK to use any mapping they want, executable space needs to be at the bottom end of address space, but I have not confirmed that in their text directly.  But despite that the chip vendor has to place something in the way of address 0x00000000 and at least 0x00000004 to allow the processor to boot (there is usually a strap on the processor core allowing for an alternate high address a bunch of ones then some number of zeros for the address).  For normal mcu operation as a consumer you will want a non volatile storage to map to address 0x00000000 that you are in control of, it can map to another address space in the executable range, some use 0x08000000 some use 0x10000000 I think or they can just leave it at 0x00000000.  This is your program, then ram is mapped elsewhere in the address space 0x20000000 or 0x40000000 are common.  

But the chip vendor can easily design it such that alternate memories can be mapped in for bootloaders, recovery, etc.  Not uncommon for some mechanism to allow for an alternate space to be mapped in instead.  Say strap an external pin on the chip one way and your program boots, strap it another way and the chip maps the boot space into a different flash or address such that a bootloader they burned into the chip can run.

Atmel used to do this on their arm7tmdi based products, called SAM-BA.  Was a very nice feature.  And other chip vendors using cortex-ms like st and nxp and silicon labs and I have not dug that deep into the others have a built in bootloader that you can use, often uart, but sometimes also i2c, spi, usb, custom.   The samd parts that I played with do not do this, they now expect you to solve the problem by burning some of your application space with their sam-ba code they have posted, and you solve the problem of how to get to the bootloader vs running the application.  What is worse the flash was not very well protected, it was trivial to write to flash without jumping through hoops, or lets say trash the flash.  Basically, if your samd part does not have a burned in bootloader from atmel, just write your own.  or do without a bootloader and use SWD as a way to get into the chip (add a $1 part from someone else that does have one, the application on that part is your in field update tool that uses swd into your samd part, hopefully you are seeing where I am heading with this).

Some cores have a register in the core that you can use to change the base address of the vector table.  this allows for example you to boot from non-volatile memory, the flash, and have alternate applications with their own vector tables, everything but reset would be used (offset 0x0008 on) from this alternate table (naturally a reset would reset the base address register back to zero causing the sp and reset vector to be read from 0x00000000 and 0x00000004).  You need to read up in the correct arm documentation for the core used in the part in question.  Not sure about this offset register, but there are some options available to the chip vendors that are described in the arm documentation for that core, with or without an fpu, 32 or 16 bit fetching, etc so you may have to experiment for each of these kinds of features to see that they really were selected by the chip vendor before you rely on them.

it is also a good idea to read the processor id and compare that to the arm documentation, it is good to have the documentation from arm for the most recent rev of that core, but you may find that the chip vendor is using an older rev of the core, so you will also want to have the documentation for that rev as well despite it being marked up as being replaced by a newer version, sometimes there are older rev nuances.  We unfortunately do not normally have direct access to the core's errata, we have to rely on the chip vendors usually to post that if at all, and the errata is VERY specific to a core revision, it is a VERY common mistake folks make to apply the wrong fix to the wrong core.  Dont be one of those people.



Short answer, this is the exception mechanism for a cortex-m core.  When the core is reset it does a read of address 0x00000000 (or an alternate high address) where you have placed the value to initialize the stack pointer.  It reads address 0x00000004 (or high address+4) for the reset vector the address in your program where the reset handler code lives, ORRED with one, let the tools orr the one on there.   The processor then checks and strips the lsbit (makes it a zero) then fetches its first instruction from that address, and depending on that instruction it continues execution.

YOU the programmer decide what value you want the stack pointer set to, and indirectly through the tools (or directly your choice) decide where the reset handler lives.

So if your memory started with

0x00000000: 0x20001000
0x00000004: 0x00000101


Then the processor after a reset would put 0x20001000 in the stack pointer register then start executing code at address 0x100