Messages

Something else you can do with the FTDI devices is set up 'aliased' baudrates, which map Wnndows COM port rates to different actual rates at the far end of the USB link. For example you can configure it so that when you say 300 baud to Windows, it actually sets 1mbaud. This is done by tweaking the divider value table in ftdiport.inf - there are a couple of FTDI apnotes on the subject.

Unfortunately Windows only supports specific baudrates.

Andy

USB-Serial devices, e.g. the FTDI parts, typically support a large range of baudrates beyond the traditional set.

A couple of further notes...
Value of U0FDR should be 0x10 ( its reset value) , not 0x00 as above. The latter value makes it not work _some_ of the time..!
I had a reply from Philips on the stack pointer issue. They acknowledged this, and suggested the SP be set to (top of RAM) -32, as this is where it gets put on a normal reset .

So the code should be :
  PLLCON=0;
  PLLFEED = 0xAA;
  PLLFEED = 0x55;
  SCS=0; // disable fast IO
  U0FDR=0x10; // no FDR - causes wrong baud
  asm("mov r0,#0x40000000");
  asm("mov r1,r0");
  asm("mov r2,#0x39");
  asm("str r2,[r0]");
  asm("mov r2,#0x7ffffff1");
  asm("add r13,r0,#0x8000"); // stack at top-32, as per Philips reccommendation LPC2136 - adjust for other processors accordingly
  asm("sub r13,r13,#0x20");
  asm("bx r2");

Just found another bug in this command - the Reinvoke ISP command does not reinitialise the SP to a place that makes sense for use when ISP is active, so if you enter with SP in an unfortunate place ( like ISP workspace, buffer that ISP is using) it falls over catastrophically during programming.
0x40000100 seems a fairly safe place to set R13 to, so add the following line to the above code, just before the bx r2 :
asm("add r2,r0,#0x100");

I posted this to the LPC2000 list a while ago - thought it may be useful to people here as well :
There are some omissions from the NXP UM (LPC2136/01) regarding the 'Reinvoke ISP' command in IAP (this is used to get into the bootloader where the P0.14 pin is not easily accessible)

Before making the call to start the bootloader, you need to set SCS to 0 to disable fast IO, and set U0FDR to 0 to disable the fractional baudrate divider.  I suspect the same issues apply to all parts with FIO and fractional baudrate divider.

This code (IAR) works :
__arm void startboot(void)
  {
__disable_interrupt();
   PLLCON=0;
   PLLFEED = 0xAA;
   PLLFEED = 0x55;
   SCS=0; // disable fast IO
   U0FDR=0; // no FDR - causes wrong baudrate if <>0
   asm("mov r0,#0x40000000");
   asm("mov r1,r0"); // even though no return expected, R1 MUST be initialised!
   asm("mov r2,#0x39");
   asm("str r2,[r0]");
   asm("mov r2,#0x7ffffff1");
   asm("bx r2");
}

There are situations where it would be useful to be able to force a device reset after successful programming (via software, not the reset pin).
The sort of situation I'm thinking about is where the bootloader is started using the 'reinvoke ISP' command from within the application. This allows the firmware upgrade process to be started down a serial link (via a serial command to the app software to invoke the bootloader), but there is then no way to remotely get out again.
I've done a couple of jobs recently where we temporarily installed a radio modem for remote configuring and diagnostics, and the ability to also reprogram firmware over the same link without writing our own IAP code would be nice.

This could be achieved fairly easily by downloading & executing a short piece of code that switched on the watchdog and allowed it to time out. (This would be preferable to a simple branch to 0 as it ensures all hardware is in its normal reset state)