Problems with flashing a 2106

Started by ws kendall April 10, 2006
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

An Engineer's Guide to the LPC2100 Series

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