T and G commands
2006-01-11 by philips_apps
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