Lpc2000

Dear philips_apps,

I am very pleased that you have finally chosen to repsond to two of
the three core issues I raised in this forum.

I am anxiously awaiting confirmation of third issue relating to CSI
vulnerability.

Arising from explanation of T and 'tEsT' arguments, please clarify:

1/  if the T command disabled when CEP is enabled;

2/  if it is corect to say that what happpens to the boot sector code
is indetermine should any user enter "G tEsT A" or "G tEsT T"; and

3/  if you knew about these when you posted the "CRP Update" message.

Thank you.

Jaya

--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...> wrote:
>
> 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
>