Both devices have on-chip bootloaders that will always be executed. With the LPC17xx, you can write a secondary bootloader to execute custom code that will run directly after. You simply need to direct your IDE to place the code at location 0x00.
On the documentation page, have a look at AN11257 and AN11258. These discuss creating secondary bootloaders (SBL) to load code from SPI or I2C respectively. This could retrieve code from a PC or an external memory device.
From AN11257:
In these MCUs, the primary boot loader resides in the boot block. The
boot loader is executed every time the part is powered on or reset.
It can execute the ISP command handler or the user application code,
which is stored in sector 0 of internal flash memory.
The SBL in
this project refers to a user-defined application that provides the
user with an option to update the User Application Firmware or
execute the previously programmed User Application Firmware. It is
placed from the address 0x00 so that when the primary boot loader
runs user application, it executes first.
I couldn't find similar documentation on the LPC13xx. But it's primary bootloader has a bit more functionality built-in. Specifically the ability to load new programs via UART. Your version lacks the USB functionality they talk about in the User Guide:
The bootloader code is executed every time the part is powered on or
reset (see Figure 63). The loader can either execute the ISP command
handler or the user application code, or it can obtain the boot image
as an attached MSC device through USB. A LOW level during reset at
the PIO0_1 pin is considered an external hardware request to start
the ISP command handler or the USB device enumeration without
checking for a valid user code first. The state of PIO0_3 determines
whether the UART or USB interface will be used:
• If PIO0_3 is sampled HIGH, the bootloader connects the LPC134x as a
MSC USB device to a PC host. The LPC134x flash memory space is
represented as a drive in the host’s Windows operating system.
• If PIO0_3 is sampled LOW, the bootloader configures the UART serial
port and calls the ISP command handler.
Remark: On the LPC131x parts (no USB), the state of pin PIO0_3 does
not matter.
You can still make the first instructions executed after the primary bootloader act as a custom secondary bootloader. You just need to locate that code at the proper address. How this is done is heavily dependent on your IDE. Refer to your IDE's documentation on how to properly control code placement into the desired sectors.
I would expect the GNU tool to do exactly what you need. It is a standard Cortex-M0, so the code generated will work. However, you will need startup code to initialise the peripherals, and library code to use the peripheral interfaces.
Atmel are pushing people to use their Atmel Studio software for upload.
AFAIK, there is no guarantee that software can be uploaded via UART on a raw (newly manufactured, unprogrammed) AT SAMD10. Looking at the AT SAMD10 datasheet there is no serial bootloader built into the chip.
So you need to load one, and flash it into the chip. This, of course, is a 'chicken and an egg' bootstrapping problem. I've done a quick web search, and haven't found a serial bootloader for the SAMD10, so their may be no serial bootloader, and you'll have to write it.
Instead of a serial (USART) botloader, you could use a hardware upload/debugger which connects over the ARM two wire SWD interface (the two pins SWDIO and SWCLK). This can program a raw AT SAMD10.
Look at the AT SAMD10 datasheet 6.2.2 "Serial Wire Debug Interface Pinout" for more details.
The SAM D10 Xplained Mini demo-board includes a hardware upload/debugger. They are under $10, so that is likely the cheapest way to get an upload system. The interface is USB.
You could buy more expensive products from Atmel, or look at OpenOCD (though I can't find SAMD10 support), or look at other hardware debuggers like Segger J-Link.
The issue is not that ARM's SWD interface is proprietary, it is the protocol from the host to the debugger which is the problem.
That will need some software to drive it. AFAICT BOSSA from Shumatech provides an Open Source alternative to the Atmel SAM-BA utility. Unlike the Atmel SAM-BA utility they say "Versions of BOSSA are available for Windows, Linux, and Mac".
Best Answer
In fact it's quite easy - there are multiple methods. I outlined one in this thread.
Basically you will have two separate pieces of software running. Consider the following setup (it's just an example):
(of course, those are dependent on your requirements)
Now, the application will download the binary (we'll call it FW 2.0). It will set some special bit in your controller and perform a reboot. Your CPU always starts at address 0x0000, it will load your bootloader. Your bootloader checks if the "special" bit is set and will then flash the binary file to address 0x1000-0x2000. It will then reset that special bit, indicating no new firmware is available. It will then reset itself again. Now, again, the bootloader starts - it will detect that the special bit is in fact NOT set and do nothing but simply perform a jump to the application (0x1000) from where the program will execute (now with the new firmware).
You might also want to include an option to run a default firmware or to load a firmware via UART in case your application cannot be written correctly or power is lost during the update.