As already pointed out by "900ss D." it can cause trouble if the
update-code gets copied to RAM and deletes the old application during
the update procedure. If update failes i.e. because of a power-failure
the application code in flash and the update-code in RAM are lost and
firmware has to be rewritten to flash using ohter channels (factory
bootloader, JTAG...).

You might check the documentation how software-protection is
implemented. Some target have limitations which flash-pages can be
written from application code if protection. Even if it's possible
disabling the protection temporarly might not be an option since this
might open a security hole for a short time. Maybe there are also
non-volatile settings or external pins to set the default start-address
(I can not rememeber this for Stellaris devices. But maybe there are
options like this.)

Possible appoaches:
(1)
- inital programming of the memory with the vector table at the start of
flash and the update code (=bootloader) at the end of flash.
- the reset-address in the vector points to the update-code's
reset/startup-routine
- the bootloader has its own vector-table to handle its interrupts and
the first instructions of the update-code remap to this vector-table
- the update code tests for an update request. Maybe by waiting for a
special package received over ethernet until a timeout of by checking if
a key is pressed.
- if there is no update request the bootloader checks if there is a
user-application in flash. This could be done by checking for a
version-number or "magic-number" at a known memory address or simple by
checking for empty flash
- if there is an update request the update code receives the flash-image
and writes it to flash but changes the reset-vector address before
writing the applications vector so the update-code is always started
first. The reset address of the user-application gets stored at a known
memory address, maybe in one of the reserved elements of the vector
table.
- after update or after timout the bootloader sets the stack-pointers,
remaps the vector-table to the default, reads the applications address
from the known locations and finally jumps to it

The advantage of this approach is that there is no special memory layout
needed for the user-application and no need to take care of remapping in
the user-code. Everything "special" gets handled by the bootloader.

(2)
- bootloader including its vector-table gets installed at the beginning
of the flash-memory
- bootloader always starts first, checks for update request as outlined
above.
- user-application starts at a known address after the end of the
bootloader-code.
- bootloader tests of update-request, receives new code, writes it to
flash
- after update or if there is no update request the bootloader reads the
reset-vector of the application from the known start-address, sets the
stack-pointers and calls the user-applications reset-handler. Optionally
the bootloader can already remap the vector-table address but this could
be also done in the reset-handler of the user application
- the user-application needs to be linked to start at the known address.
The address needs to be a valid postition for a vector-table (valid
addresses/aligments should be listed in the documentation). For this
minor modifcation are needed in the linker-script or special
command-line options need to be passed to the linker

I have implemented both approaches successfully with STM32 devices where
firmware updates get read from a SD-Card. So the basic concepts do work.
But of cause TI/LMI Cortex M3 devices are different in terms of
in-application-programming and there may be differences in handling the
vector-table location/offset.

Hope this rather long post gives at least an idea.