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.
What is the chipset that is used [in the] [Yún] board for USB communication [...] ?
The Arduino Yún has two USB interfaces:
- A USB interface built in to the ATmega32U4-AU which manages serial comms.
- A USB 2.0 hub based on an AU6350
See schematic
The ATmega32U4 provides a dedicated UART TTL (5V) serial communication. The 32U4 also allows for serial (CDC) communication over USB and appears as a virtual com port to software on the computer. The chip also acts as a full speed USB 2.0 device, using standard USB COM drivers.
...
The Yún appears as a generic keyboard and mouse, and can be programmed to control these input devices using the Keyboard and Mouse classes.
See Arduino Yún
Best Answer
It is working now. It is a little weird that I needed to plug in a USB-Serial converter to the DB9 converter apart from the power USB. If anyone else has a similar problem, just plug in both the USB and the Serial cables in the ports and it should work.
Thanks to those who helped!