Another approach (which I used for several projects) is to let the main application handle the download/reception of the new firmware and "instruct" the boot loader to execute it upon reset.

1. Main application implements communication interface to receive update (USB, UART etc.)
2. Data is stored on external memory (serial flash for example)
3. After successful reception (checksum calculation), the main program signals the boot-loader that an update is available (write flag/update status "update available" to EEPROM for example)
4. Main application issues software reset
5. Boot loader reads update status information, verifies and executes the update.
6. After the update has been completed, boot loader sets update status to "executed"
7. Boot loader jumps to main program
8. Main program may recognizes that an update was executed (and maybe perform some special actions) and sets the update status to "none"

In comparison to the approach where only the boot loader is involved:

Pros:

• No reset required and no timing restriction to initiate update
• Complex communication interface / protocol possible due since you are not limited to small boot section flash size
• Better control of update mechanism
• Decouples the communication interface from the boot loader (the reception mechanism can be updated/changed)
• Main application "knows" about the (upcoming) update and can react (perform data migrations, configuration updates, give user feedback like "updated from v1.22 to v1.3" etc)

Cons:

• External storage required (if you never use more that half of the main flash, this could probably be abused as temporary storage)
• Slightly more complex design
• Boot loader logic is coupled to main application
• Device must be shipped with main application pre-flashed

Depending on your requirements there is somewhat different approach (to the common one you described) that might interest you.
You can let the main application handle the download/reception of the new firmware and "instruct" the boot loader to execute it upon reset.

To give you an idea how this could be implemented:

1. Main application implements communication interface to receive update (USB, UART etc.)
2. Data is stored on external memory (serial flash for example)
3. After successful reception (checksum calculation), the main program signals the boot-loader that an update is available (write flag/update status "update available" to EEPROM for example)
4. Main application issues software reset
5. Boot loader reads update status information, verifies and executes the update.
6. After the update has been completed, boot loader sets update status to "executed"
7. Boot loader jumps to main program
8. Main program may recognizes that an update was executed (and maybe perform some special actions) and sets the update status to "none"

In comparison to the classic approach where only the boot loader is involved:

Pros:

• No reset required and no timing restriction to initiate update
• Complex communication interface / protocol possible due since you are not limited to small boot section flash size
• Better control of update mechanism
• Decouples the communication interface from the boot loader (the reception mechanism can be updated/changed)
• Main application "knows" about the (upcoming) update and can react (perform data migrations, configuration updates, give user feedback like "updated from v1.22 to v1.3" etc)

Cons:

• External storage required (if you never use more that half of the main flash, this could probably be abused as temporary storage)
• Slightly more complex design
• Boot loader logic is coupled to main application
• Device must be shipped with main application pre-flashed