LPC1114 ISP Connections

Started by tchelobh, January 22, 2013, 08:01:02 AM

Previous topic - Next topic

tchelobh

Hi, that's my first post here.

And i have a very simple doubt. I'm designing my first board with LPC1114, and i'm intended to use flashmagic to flash it. I've readed that i need to Pull the ISP pin (PIO0_1) to 3v3, pulse reset and send data over RXD/TXD. The RTS/CTS signals can do this for me?

I should use the circuit described in http://www.flashmagictool.com/assets/resources/ISPHardwareEntryAppNote.pdf, connecting the /PSEN signal to my ISP pin?

Thanks for the advice.

Andy Ayre

CTS is an input - can't be used. /PSEN is for 8051 devices. See:

http://www.keil.com/mcb1000/mcb1000-schematics.pdf

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

tchelobh

Thanks Andy.

One more doubt, someone here were able to use the FT231X chip to flash a LPC1114 over usb?

http://www.ftdichip.com/Support/Documents/DataSheets/ICs/DS_FT231X.pdf

I'm afraid because i've had some bad experiences with prolific chips, and no experience with FT2XX chips...

Thanks,


Andy Ayre

In my experience FTDI chips work well.

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

jcasey


I've used Flashmagic many times for the NXP ARM7 family...
In the past, I've always used a MAX232 to convert the RS232 signals from a USB-Serial cable,
and a couple of 3904 transistors to pull the RESET and BOOTSEL lines down for ISP, just as in
the specs.  Never had a problem, done this for many years on dozens of designs.

I've got a new board that I used a FT231XS on.  I'm getting very strange behavior talking to
my LPC2103.  I can examine, erase, check blank, etc. with FlashMagic just fine.  I can program
once.  After the chip is programmed, it won't respond to any ISP attempts anymore. 

At first I thought I might have a bad cpu, so I swapped it out.  Same symptoms, it burned once,
then no more.  I probed and found that SOMEtimes, the terminal emulator in FlashMagic got me
into the ISP...so I was able to manually enter the commands to autobaud and erase all memory by
hand.  Then it worked fine again...I could do any ISP commands I wanted until I programmed once,
then it locked up.  I've been through this cycle many times now.

I've scoped the signals, both RESET and BOOTSEL seem to be expressed properly. 
The symptom is that the serial TX is going from the FT231XS, but the cpu isn't responding on RX
on these ISP attempts.  It is as if it won't recognize the RESET/BOOTSEL combo once programmed.

I've stripped the code that is getting burned down to nothing at all...I can't be doing anything to
offend it.  All interrupts off, simple polling loop to oscillate a pin or read UART0, add 1, spit it back
work fine, so the code is executing.

This symptom is unique to using the FT231XS, but I can't figure out why.  Any ideas?

jcasey


I should add that I'm using FlashMagic 5.02.1661.
I know it is old, but it works fine on the LPC2103 on other hardware configs.


jcasey


Two more notes: 
1)  I upgraded to the latest version of FlashMagic available here.  No difference.

2)  I just cut the RX and TX traces and patched in my usual ISP tool, with the
USB-serial cable & MAX232 interface... same code, same cpu, same FlashMagic
settings...just now bypassing the new USB/serial chip.  Works fine, multiple ISP
cycles with no issues.

Folks are saying that these chips work fine.  What are they doing differently?

Andy Ayre

Can you compare the waveforms on the pins of the device? There must be a timing difference. Perhaps adjusting T1 and T2 in the Flash Magic options might help?

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

jcasey

Hi Andy - thanks for responding.

Waveforms should work, but are puzzling.

If the flash is erased, it is simple:
  P0.14 goes lo, and 900us later \RESET goes lo.

If the flash is not erased, it bounces, but P0.14 is nevertheless low when \RESET goes lo:
  P0.14 goes lo
   300 us later, P0.14 goes hi
   900 us later, P0.14 goes lo
   1.1 ms later, \RESET goes lo

In either case, P0.14 stays low for 200ms, while \RESET stays low for 500ms.

I'm having a hard time understanding how the existance of code running in the cpu
can bounce the P0.14 line, unless I was driving P0.14...which I'm not.

I've checked about 45 times, P0.14 is programmed as GPIO in, not out.
(FIODIR0 is set to 0xFFFFBF3C...and I've tried setting it to 0 just to make sure...)




jcasey

Let me amend that, it is even messier.

I was testing the "working" situation by doing a "flash erase", so that I didn't revert to unworkable.

It turns out that a "flash erase" does not double bounce the P0.14 line in either case (blank & working, programmed and not working).

The request to program, however, double bounces P0.14 as I stated when it is programmed and not working, but does not when blank and working.
In the latter case, P0.14 goes low, then \RESET goes low  (in this case 800 us later, but I've been playing with T1 and T2 settings).

The T1 and T2 settings, by the way, make no difference in any of this behavior.

jcasey


One more possibility, given that we're seeing a "bounce"....
I beefed up the bypass cap on the FT231XS, from 0.1 to 0.1 parallel 1.0 uF.
Didn't make any difference.

I should note that I'm also trying to get action on help sites for FTDI and NXP,
but you are responding fastest, which I appreciate greatly.

If you want to take the conversation off-forum, you can email me or call me.
We can post the wisdom gained at the end here.

casey@rockfieldresearch.com
1-702-487-6970  (pacific time)


tchelobh

Hey jcasey,

I have no ideas how to help, and i'm afraid that i will have the same problem. I'm assembling some boards with FT231X and i'll try to use them to flash a LPC1114.

Please, if you come to a solution, post here, or e-mail me at marcelo.beling@geraestec.com.br

Thanks,

jcasey


update:  I'm in communication with an ap engineer at FTDI.  This chip is fairly new,
and he doesn't know of anybody using it for NXP ARM programming yet.  (Anybody?
Speak up?  Bueller?  BUeller?)     He says that they have cables they use for programming
LPC1xxx series micros with FlashMagic, but they use the older family FTDI chips (the 232R),
and they do NOT use the DTR line, but they ground the bootsel pin and use the
"FTDI USB-DONGLE" interface selection.  Not a lot of help so far, but we're trying.

NXP is dog slow to respond to tech queries...anybody know anybody there who can give
a quicker answer?


jcasey


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.

jcasey

#14
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 mis-labelled....pin 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.

Jeff