The official webpage goes through how one should program their Arduino Due using the Arduino software.
For those who are going to develop a project without Ardunio but with basic g++, one must understand how to program his chip. Apparently, the Due - SAM3X - has a booting process somewhat different from the AVR, and it is not quite the same as firing up the "avrdude" and be done with it. Ardunio has designed the board such that flashing firmware is easier than what the stock SAM3X has offered, here explains the booting process and the tricks that Arduiro implemented.
The SAM3X comes with a built-in bootloader, called SAM-BA. Standalone SAM-BA tools could be downloaded from the Atmel website. SAM-BA is permently burned in the chip ROM straight out of factory, and is not using up any of the flash space. This is very different from AVR that AVR doesn't come with any built-in bootloader.
In addition to SAM-BA, SAM3X could be boot into right in the middle of the flash, instead of the very beginning of the flash that normally do. One could the code their own userspace bootloader in the 0-256KB, and real application in the 256KB-512KB.
So in short, there is three booting start point - SAM-BA, Flash 0 and Flash 1, this can be controlled by tweaking the GPNVM bits in EEFC0.
In Ardunio, as well as most of the scenario, code are flashed with SAM-BA tools. Flash 0/1 userspace bootloader is not used in Arduino.
SAM3X will boot to SAM-BA when: A) the GPNVM bits has been modified (set to 0) to instruct SAM3X to boot to SAM-BA. It can be done in userspace code. B) Erasing the chip (Erase button) which will also clear/zeroing that GPNVM bits and leads to the SAM-BA agoain.
In SAM-BA, firmware could be flashed over the native USB port, which will be put in CDC mode, or through the first UART channel. SAM-BA will wait indefinitely without timeout. In other words, once the GPNVM bit is cleared for SAM-BA booting, it will always be there waiting for flashing, even after power cycling.
Of couse the flash content and the GPNVM bits could be flashed over the JTAG, which will not be discussed here.
Two thing has been done by Ardunio such that users need not to press the ERASE button everytime.
The ATMEGA16U2 chip, acting as USB bridge to expose the UART as USB replacing the FTDI chip, actually does more than that.
If the host is connected to the programming port at baud rate 1200, the ATMEGA16U2 will assert the Erase pin and Reset pin of the SAM3X. Forcing it to the SAM-BA bootloader mode.
At any other baudrate, it will reset the SAM3X. This is done to simulate the behavior of the AVR-based Arduino - connect and reset.
The code, firmware of the ATMEGA16U2, currently lives in ide-1.5.x branch of /hardware/arduino/sam/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c.
When Ardurio uploads the sketch, it will actually wire up some additional C-code. One particular is that it configs the native USB port as CDC for serial communication. That specific code has similar detection of ATMEGA16U2 in place. When the port is opened with baud rate 1200, it will set the GPNVM bits apporiately for booting to SAM-BA, and reset itself.
The corresponding code lives in ide-1.5.x branch in /hardware/arduino/sam/cores/arduino/USB/CDC.cpp.
Everything after erase is just SAM-BA logics, user could connect to the SAM-BA through the SAM3X native USB, which is put into CDC mode by now. Or to the UART, through the Programming port which is also CDC but exposed by ATMEGA16U2.
In practice one should be able to use the official Atmel SAM-BA tools to flash the binaries. I have difficulty in installing it though.
Arduino use BOSSA, an open source tool that speaks SAM-BA for simple SAM configuration. Think of it as a SAM version of the Avrdude. However, There were two issues that makes BOSSA not working with Arduino Due, Arduino has commit patches to it and the patched version is shipped along the software. It might eventually get intergrated into the master branch. At the moment of this writing, the patched version is here: https://github.com/shumatech/BOSSA/tree/arduino.
Issues: 1. It does not recognize SAM3X. 2. Because SAM-BA speaks different protocol for UART (xmodem) and native USB CDC (binary), it does a "smart" detection to see if the connection is a through an USB one or not. However it's just not smart enough - the programming port connection is also a USB connection, hence it speaks the wrong protocol.
If someone is going write C from scratch, it's unlikely the On-chip CDC 1200 hack would be taken care, hence opening 1200 baud rate on the native port won't work. One could refer to Arduino's implementation for keeping the same behavior if wished.
If the native USB port is put into other use other than CDC, this obviously won't work. It is a USB 2.0 High Speed 480Mbps port, someone would possibly have make a better use of it other than CDC.
The ATMEGA16U2 would always work. Anyone unhappy of the 1200 tricks of course could modify the firmware themselves, flash it over the ICSP header with AVRISP technique.
For opening the port in 1200, one could use Putty (a open source software commonly used for SSH in Windows) to connect to the corresponding COM port. If this is done over the native USB port, after closing the connection, the port will be disappear shortly afterwards, and a new COM port with another identifier will come up, which is the SAM-BA native USB CDC.