Electronic – AVR self-programming

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

The ATmega32A Datasheet on page 245 shows the following table of where the bootloader area starts depending on how the BOOTSZ fuses are set:

So assuming you have BOOTSZ0 and BOOTSZ1 are both cleared for the largest bootloader section it will start at 0x3800. From the memory sections documentation you can see the code goes into the .text linker segment and the address may be changed by going under Project properties | Toolchain | AVR/GNU Linker | Memory Settings and adding .text=0x3800 under the FLASH segment section:

Normally if I want the bootloader combined with the application firmware for production programming I use the bootloader to load the main firmware and then read back the result from FLASH. It should be technically possible to combine them using custom linker segments but you'd have to be very careful about where things like standard library functions were placed so the former method is probably easier and safer.