Lpc2000

Hello all LPC2000 participants,

Here are some answers to the T and G command related questions that 
have been asked on this forum recently.

T command
=========
The T command was designed with the intention of expediting the 
loading of data into the on-chip RAM during Philips in-house 
testing. In essence, what the "W" command does in a serial fashion, 
using UART0, the "T" command was supposed to do using a selected 
group of GPIO pins.

The T command had to provide a one-way data transfer only (from the 
testing environment into the LPC2000). Furthermore, the data width 
was supposed to be either 8 or 16 bits and there was an option to 
select handshaking or not.

When an LPC2000 device is put into a tester, we are capable of 
controlling every single signal that stimulates the microcontroller, 
and therefore a non-handshake based upload could be possible. 
Knowing how many cycles it takes a portion of code to be executed, 
we could provide the right data at the right time at the right pins 
so that the "T" command would fetch them and store them into the RAM.

Since there are not to many environments as controllable as the one 
described above outside of a semiconductor company manufacturing 
and/or testing facilities, a simple handshake was designed: An 
LPC2000 would wait for a high-to-low transition on a dedicated pin, 
and when such event would be detected, it would fetch data from a 
parallel port.

Issuing a "T" command means that in addition to 3 pins taken by the 
ISP, additional 8/16 (byte/half-word transfer) or 9/17 (byte/half-
word transfer + handshake) would have to be used. It was our belief 
that there would not be too many real-life applications that would 
be willing to trade 8 to 17 pins for a GPIO functionality, 
especially on smaller parts (48 and 64 pin packages).

It is clear that most of those customers that would decide to use 
a "T" command could not live without a handshake. Unfortunately, 
this feature was not working in some of the early releases of the 
bootloader, and this was an additional reason why it was decided not 
to promote this feature.

Bottom line: The "T" command was supposed to fetch data from 
a "parallel" port and store it into on-chip RAM. It does not execute 
a single piece of code on its own. Even if a code is successfully 
loaded into the on-chip RAM using this command, a "G" command has to 
be issued.


G command with "tEsT" argument
==============================
The "tEsT" argument was meant to be used by Philips testing 
facilities so that a special test/piece of code residing in the 
bootloader can be called/executed. In reality it turned out that 
almost 100 tests (small applications) have to be loaded into every 
single device when testing it, in order to verify its functionality 
and say it is "OK". These tests are not carved in stone because we 
keep updating and refining them. Therefore, although it was intended 
at one point in time, we could not store all these patterns into the 
bootloader. This is why no meaningful code can be accessed using 
the "tEsT" argument in the current version of the bootloader. 

Regards,

Philips Apps Team