Author Topic: LPC1114 ISP Connections  (Read 20314 times)


  • Jr. Member
  • **
  • Posts: 10
    • View Profile
    • Email
Re: LPC1114 ISP Connections
« Reply #15 on: February 05, 2013, 06:28:46 pm »

Although I tried to search for similar before my initial post here, today I dug deeper.
The keyword to search for was "only once".  There are numerous incidents in the
past where users have noted that they could program "only once", after which
FlashMagic failed to autobaud.  In most, you got as far as diagnosing that the chip
was not responding on RX to the autobaud "?"...hence was not recognizing the
P0.14/reset combo (or equiv for that chip).

This is exactly what I'm getting now...albeit it only happens with the FTDI serial
interface, and not with a commercial USB cable (perhaps with the same chip?) and
a MAX232 and two 2N3904.

Andy - can you recall any common themes in those past cases....resolution or settings,
or related problems.  I am almost certain that this fault lies on the NXP end, but they
don't respond, and you are right on the cutting edge of this.

One thread on this forum, by "whitewing" on 4/19/09 discusses "Reinvoking ISP", which
is close, but really involves calling ISP from within the code.  It does mention that several
things aren't liked by ISP -- high speed GPIO access, fractional baud rates, PLL clock boost,
etc.....but I can't see how to turn those off in anticipation of a forced reboot....and in any
case, I just tried loading a clean copy of code that did none of those things, but it still
inhibited re-entering ISP once programmed.

Perhaps the cpu needs a long time between the reset and the send of the "?" for autobauding?
Do you have a version of FlashMagic where that delay is extendable with a parameter setting?
This might explain the difference with the FTDI chip -- the USB interface might be packetizing
the commands for TX and handshake lines, and thus spooling them out on the hardware end
faster than FlashMagic intends....if I could set a long delay here and set the parameters for the
FTDI interface to a zero length buffer before sending, I might get it to work.

Help, please.


  • Jr. Member
  • **
  • Posts: 10
    • View Profile
    • Email
Re: LPC1114 ISP Connections
« Reply #16 on: February 05, 2013, 07:34:11 pm »
mea culpa --

I am modifying an earlier post, but leaving my original comments below just
to let you enjoy my stupidity.  I thought I had the answer as a timing problem
from packetization in the USB chip....but it was much simpler and much stupider.

I had the RTS and DTR lines swapped.  Unfortunately, my standard tool, which hooks
to a 9-pin serial cable, had the correct functions going to the correct pins on the
ARM (i.e. pin 4 triggered a transister to pull down RESET, pin 7 to P0.14).  My
schematic, however, had these pins 4 was labelled RTS and 7 DTR,
rather than the opposite, which is correct.

This worked fine for me for many years...and I now have to think long and hard about
other places this mistake might have worked into.  When I opened up that drawing to
make the prototype with the FTDI chip, I copied the functions to the pins on their
chip, thus swapping RTS and DTR.  When I cut the traces and reswapped them on this
board, all works fine.

The reason that it worked fine when the chip was unprogrammed was that it was already
running ISP code, due to the lack of valid code in the flash.  That required only a reset
to restart ISP, not a reset/bootsel combo in the proper sequence.  

I have no idea how I got those labels wrong in the first place -- I had thought that I
copied the whole thing directly off the help pages of a very early version of FlashMagic,
when it was still labelled as a Phillips ap, but I must have miscopied.

My apologies for all the bandwidth wasted.  I hope this thread helps somebody else
avoid this time wasting error.  

*** To be perfectly clear, the FT231XS appears to work great with FlashMagic and
the ARM LPC2103 ***

note -- everything below here is incorrect......
>got it -- the problem, anyhow, if not the solution.

>when using the "good" interface, with a standard serial I/O usb cable and a MAX232 and transistors,
>the delay between the release of reset and the transmission of "?" is adjustable with the T1 and T2
>parameters in Flashmagic, and is never less than 450ms.  it always works.

>when using the FTDI USB chip interface, the delay is always 340ms, and totally ignores the T1 and
>T2 settings in Flashmagic.  

>clearly, the handshake line transitions are packetized, and are not sent until the next transmission.

>The difference between 340 ms and 450 ms must be enough so that the ISP code has not initialized,
>and is not ready to queue up the "?", thus it never receives it.  It "works" when the chip is blank because
>there is no valid code onboard, so the ISP code is already running.  Even if it reinitializes on the new reset,
>the pointers are in place so that the received autobauding "?" is queued up and responded to.  That 340ms
>is the same whether the chip is programmed and doesn't respond to ISP, or is blank and does.

>I have asked my contact at FTDI if they can modify their drivers to flush buffers when they receive a
>transition on the handshaking lines at the PC end...hopefully this is all doable that way, without needing
>a change in microcode in the FTDI chip.

>Another option is to set the driver for a zero-length buffer for packetizing the USB serial I/O.  This is woefully
>inefficient, but would work.  I thought I had done this, but I had just minimized it.  The minimum is 64 bytes,
>and that isn't small enough.

>I'll post here when this gets resolved.  If anybody has more wisdom to shed on this, I'd sure like to hear it.

« Last Edit: February 05, 2013, 09:30:03 pm by jcasey »

Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2190
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: LPC1114 ISP Connections
« Reply #17 on: February 09, 2013, 09:21:08 am »
Sorry for not responding - I was sick. Thanks for closing the loop on this. One of the challenges of supporting Flash Magic is that we can't see the hardware being used. :)

Embedded Systems Academy, Inc.
support at esacademy dot com