Lpc2000

I'm new to this group and to the 2000 architecture.  I have a design that 
was initially coded on the IAR 2106 dev board.  We've now moved that to our 
own hardware.

The problem that I'm experiencing is that I cannot flash the controller on 
my hardware more than once.  Once flashed, the controller is unresponsive 
to attempts to connect to the loader.  The design is a mixed 3v/5v 
design.  I discovered that I was driving the controller's reset pin with a 
5v signal (banging my forehead on the desk).  So, we hacked the board and 
are now driving reset with a 3v signal.  I had thought that that would 
solve my problem - 5v eventually burns out the reset pin circuit so of 
course I can't communicate with the loader because I can't reset the 
controller.  Application code runs fine.

While the 5v on a 3v pin surely must have contributed, it doesn't seem to 
be the entire cause.  We fixed the 5v reset problem but still can only 
program virgin controllers.  Since, P0.14 is a port pin I didn't change the 
circuit that drives it.  Now I've gotten to wondering if that pin and the 
perhaps the Rx/Tx connections to serial 0 must also be at 3v levels during 
programming.  The data sheet appears somewhat vague about just which pins 
are 5v tolerant but it does say that there are 32 general purpose I/O pins 
that are and interestingly enough, P0 just happens to be 32 bits wide, 
therefore I can assume, can I not, that those are the pins that are 5v 
tolerant?

If any of you have had this or similar problems with flashing the 210x 
family, I surely appreciate whatever help you can send my way.

There isn't any "security" bit somewhere that would prevent me from 
connecting to the loader is there?  That makes no sense to be but there 
have been stranger things ...


Scott

Systronix, Inc
Salt lake City, Utah

Em Seg 10 Abr 2006 18:26, ws kendall escreveu:
> I'm new to this group and to the 2000 architecture.  I have a design that
> was initially coded on the IAR 2106 dev board.  We've now moved that to our
> own hardware.

Me too. Unfortunatelly I never had such problems, the best I can is to say to 
you wath may NOT be the problem...

> The problem that I'm experiencing is that I cannot flash the controller on
> my hardware more than once.  Once flashed, the controller is unresponsive
> to attempts to connect to the loader.  The design is a mixed 3v/5v
> design.  I discovered that I was driving the controller's reset pin with a
> 5v signal (banging my forehead on the desk).  So, we hacked the board and
> are now driving reset with a 3v signal.  I had thought that that would
> solve my problem - 5v eventually burns out the reset pin circuit so of
> course I can't communicate with the loader because I can't reset the
> controller.  Application code runs fine.

If the application runs fine, you didnt burnt the reset pin.

> While the 5v on a 3v pin surely must have contributed, it doesn't seem to
> be the entire cause.  We fixed the 5v reset problem but still can only
> program virgin controllers.  Since, P0.14 is a port pin I didn't change the
> circuit that drives it.  Now I've gotten to wondering if that pin and the
> perhaps the Rx/Tx connections to serial 0 must also be at 3v levels during
> programming.  The data sheet appears somewhat vague about just which pins
> are 5v tolerant but it does say that there are 32 general purpose I/O pins
> that are and interestingly enough, P0 just happens to be 32 bits wide,
> therefore I can assume, can I not, that those are the pins that are 5v
> tolerant?

Yes, they are. I program my LPC2106 devices with a simple MAX232 (the ones I 
could find to buy on local electronic components sales) powered at 5V. The 
LPC2106 TX has enough voltage to drive the MAX232 and the RX works fines with 
5V signals. So far I programed about 10 pieces, all worked fine. 
So, maybe thats not the problem to you.

I take a little care with P014. I put a pull up resistor on it, 100k ohms, to 
+3,3V, and another resistor, 4,7k ohms, to my programming connector. That pin 
on the conector is connected (in my "programmer") to switch wich connects 
that pins to ground. So, when I select my switch to ISP, I have on P0.14 a 
resistor divider with 100k and 4k7 to give him a low signal. With the switch 
open, or my programmer disconnected, the pin becomes high with the 100k 
resistor. Works fine. Its nice because I use the UART0 for debug pouposes, so 
with the ISP switch opened I use the serial port for debug, with the switch 
closed, I use to program it.
I made it with the Philips ISP program, and in Linux (most of the time) with 
the lpc21isp program. The only issue I founded is that the lpc21isp do not 
configures correctly the serial board. I allways has to open minicom, close 
minicom (the serial port becomes reconfigured) and then I run lpc21isp. 
When (or if) I finish my actual project, I will work on lpc21isp to correct 
this...

> If any of you have had this or similar problems with flashing the 210x
> family, I surely appreciate whatever help you can send my way.
>
> There isn't any "security" bit somewhere that would prevent me from
> connecting to the loader is there?  That makes no sense to be but there
> have been stranger things ...

No, unfortunatelly not. LPC210X do not have any kind of protecting for the 
firmware, wich is making me to not sleep...

> Scott
>
> Systronix, Inc
> Salt lake City, Utah
>
Xultz
Curitiba - Brazil

> I made it with the Philips ISP program, and in Linux (most of the
time) with 
> the lpc21isp program. The only issue I founded is that the lpc21isp
do not 
> configures correctly the serial board. I allways has to open
minicom, close 
> minicom (the serial port becomes reconfigured) and then I run lpc21isp. 
> When (or if) I finish my actual project, I will work on lpc21isp to
correct 
> this...

I have been using LPC21isp for a while now to program my Olimex
LPC2106 board.  I can't use it if minicom is open but other than that,
I have never had an issue.

After programming I can open minicom for debugging.  It turns out that
the programming and debug serial rates are the same (115200) but I
don't know that it matters.  I have not tried the term feature of
lpc21isp but it might be interesting.

From my makefile:

program	: ${TARGET}.hex
 	  lpc21isp ${TARGET}.hex /dev/ttyS0 115200 14746

I am using version 1.31 compiled locally.

Richard

Hi lpc2000,

I have seen this question sometimes on this list. I think many users find
the problem of the serial port programming only working for the first time
on the user designed boards. I think this is caused by the wrong BSL or
RESET pin timing at power on prevents the controller from going into
bootloader mode.

The controller must be in bootload mode for the serial port programming to
work. If the BSL or RESET pin timing is wrong, an unused controller will
still go in to bootloader mode because there is no valid user code to
execute (this is why it works for the first time). After the first time it
is necessary for the BSL and RESET pin timing to be correct, otherwise the
last programmed user code is executed.

Kind regards,

Nic

Thanks all.

Nic:

What you wrote caused me to wonder about the timing.  Of course, since the 
timing is controlled by the Philips Flash Utility, then how could it be 
wrong?  An inspection with a 'scope showed that it is correct - sort 
of.  What isn't right is that the two important signals RTS and DTR are 
changing state at the wrong time - ISP enable is released about 330mS 
before RESET is released.  That couldn't be right.  But I didn't bugger up 
the measurement ISP enable really is bein released before RESET.

Standard DE-9 serial pinout has DTR on pin 4 and RTS on pin 7.  Now, if you 
look at figure 2 of the Philips app note 10302 you'll see that they have 
DTR on pin 7 and RTS on pin 4.  In paragraph 3.2 they associate RTS with 
RESET and DTR with ISP Enable.  This text reference reenforces the signal 
names used in Figure 2.  So, if you design your hardware - as I did - 
following the signal nomenclature then you won't be able to program the 
controller after you've done it once.  Bloody hell.

Dropped a breakout box in the serial path, swapped DTR and RTS, and la, I 
can flash the 2106 to my hearts content.


scott

Systronix, Inc
Salt Lake City, Utah




At 21:31 2006-04-10 -0700, you wrote:

>Hi lpc2000,
>
>I have seen this question sometimes on this list. I think many users find
>the problem of the serial port programming only working for the first time
>on the user designed boards. I think this is caused by the wrong BSL or
>RESET pin timing at power on prevents the controller from going into
>bootloader mode.
>
>The controller must be in bootload mode for the serial port programming to
>work. If the BSL or RESET pin timing is wrong, an unused controller will
>still go in to bootloader mode because there is no valid user code to
>execute (this is why it works for the first time). After the first time it
>is necessary for the BSL and RESET pin timing to be correct, otherwise the
>last programmed user code is executed.
>
>Kind regards,
>
>Nic
>
>
>
>Yahoo! Groups Links
>
>
>
>