Hi all.
I have a problem with programming via UART on LPC2294 system.
I using USB to UART interface with FTDI FT232BM chip. When I check LPC
signature, all is OK, ISP programmer found LPC chip (PartID:84016915
BootLoader:1.61). But when I erasing chip, all is OK,
programming sector 0 is OK, on sector 1 chip burner give me message
"Canceled, not responding". I am using ./lp2k_pgm , when I try it in
windows and LPC210x_ISP burner, it failed also with message "Board not
responding". I restart it using DRT signal, next I check it and it
works, but stopped again at second sector. When I connect other
simmilary board to burner, it works OK, it programmed all sectors..
Afer time, when I don't working with it, LPC start sending to me
various data, all are 10 digits numbers ended EOL character. What is it ?
Any suggestion where is problem ? Start a New Thread

--- In l..., "Boris Kralik" wrote:
>
> Hi all.
> I have a problem with programming via UART on LPC2294 system.
> I using USB to UART interface with FTDI FT232BM chip. When I check LPC
> signature, all is OK, ISP programmer found LPC chip (PartID:84016915
> BootLoader:1.61). But when I erasing chip, all is OK,
> programming sector 0 is OK, on sector 1 chip burner give me message
> "Canceled, not responding". I am using ./lp2k_pgm , when I try it in
> windows and LPC210x_ISP burner, it failed also with message "Board not
> responding". I restart it using DRT signal, next I check it and it
> works, but stopped again at second sector. When I connect other
> simmilary board to burner, it works OK, it programmed all sectors..
> Afer time, when I don't working with it, LPC start sending to me
> various data, all are 10 digits numbers ended EOL character. What is
it ?
> Any suggestion where is problem ?
>

There are defects in the LPC boot loader implementation that causes it
to fail especially when driven professional systems including FT232BM
based UARTs. The UART problem documented here:

http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html

You may wish to try SILL to see if it works for you:

http://www.cse.unsw.edu.au/~jayas/esdk/sill.html

Hope this helps.

Jaya Start a New Thread

Jaya,
not to "stir the pot", but what do you exactly mean with:

"especially when driven professional systems including FT232BM based
UARTs" ?

in particular "especially" ?

Regards,
Carsten
>
> There are defects in the LPC boot loader implementation that causes
it
> to fail especially when driven professional systems including FT232BM
> based UARTs. The UART problem documented here:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
>
> You may wish to try SILL to see if it works for you:
>
> http://www.cse.unsw.edu.au/~jayas/esdk/sill.html
>
> Hope this helps.
>
> Jaya
> Start a New Thread

On Monday 18 September 2006 15:32, Carsten Gr wrote:
> Jaya,
> not to "stir the pot", but what do you exactly mean with:
>
> "especially when driven professional systems including FT232BM based
> UARTs" ?
>
> in particular "especially" ?
>
> Regards,
> Carsten

Hello Carsten,

his site explains what he means. "professional system" might not be the best
paraphrase, but he's talking about UART implementations that are able to
output data at the full baudrate with no additional gaps except for the
configured start and stop bits. Apparently, the FT232BM is able to do that,
while some PC parallel ports (probably best described as "consumer systems",
as opposed to "professional systems") might not.

Anyway, it's all on his site, and in this newsgroup's archive.

Regards

Dominic



Start a New Thread

--- In l..., Dominic Rath
wrote:
>
> On Monday 18 September 2006 15:32, Carsten Gr wrote:
> > Jaya,
> > not to "stir the pot", but what do you exactly mean with:
> >
> > "especially when driven professional systems including FT232BM
based
> > UARTs" ?
> >
> > in particular "especially" ?
> >
> > Regards,
> > Carsten
>
> Hello Carsten,
>
> his site explains what he means. "professional system" might not
be the best
> paraphrase, but he's talking about UART implementations that are
able to
> output data at the full baudrate with no additional gaps except
for the
> configured start and stop bits. Apparently, the FT232BM is able to
do that,
> while some PC parallel ports (probably best described as "consumer
systems",
> as opposed to "professional systems") might not.
>
> Anyway, it's all on his site, and in this newsgroup's archive.
>

Without wishing to re-open this, the specific claim Jaya makes is
just plain wrong. It is quite possible to use the LPC2xxx UARTs with
no gaps (or indeed at low bit rates): this is easy to demonstrate.

Brendan



Start a New Thread

I would expect so :o)

(and I would also expect Philips (or NXP) to chime in IF there were
ANY problems, and I would also expect them to put it in the errata
sheet....)

On the (so far) 5 different 2148 designs I've been working on, I have
yet to see any error on the UART's...
Hot air...

regards,
Carsten
--- In l..., "Brendan Murphy"
wrote:
> Without wishing to re-open this, the specific claim Jaya makes is
> just plain wrong. It is quite possible to use the LPC2xxx UARTs with
> no gaps (or indeed at low bit rates): this is easy to demonstrate.
>
> Brendan
> Start a New Thread

--- In l..., "Boris Kralik" wrote:
>
> Hi all.
> I have a problem with programming via UART on LPC2294 system.
> I using USB to UART interface with FTDI FT232BM chip. When I check LPC
> signature, all is OK, ISP programmer found LPC chip (PartID:84016915
> BootLoader:1.61). But when I erasing chip, all is OK,
> programming sector 0 is OK, on sector 1 chip burner give me message
> "Canceled, not responding". I am using ./lp2k_pgm , when I try it in
> windows and LPC210x_ISP burner, it failed also with message "Board not
> responding". I restart it using DRT signal, next I check it and it
> works, but stopped again at second sector. When I connect other
> simmilary board to burner, it works OK, it programmed all sectors..
> Afer time, when I don't working with it, LPC start sending to me
> various data, all are 10 digits numbers ended EOL character. What is
it ?
> Any suggestion where is problem ?
>

Yes. The PC software. There has not been a single credible demonstation
of weakness in LPC2xxx UART parts. There are huge weaknesses in PC
software that uses UARTs.

I reviewed various open source UART approaches. It is like a horror
gallery. My own Hidprobe (not open source) can even be massively
improved with some more care.

John Heenan Start a New Thread

Just figured I can't be alone in migrating from Carm to RealView compilers
and as such given the current lack of an _at_ command for the RealView
compiler you're left with a far less obvious way in which to use the linker
to lock flash (assuming your chip supports the mechanism at 0x1FC.

So much so it took a little while for the guys at Keil to come up with a
suitable solution as well, however I figured now that it's done it would be
of use to some of you (and might hopefully save you a weeks worth of trying
to figure it out for yourselves...)

Keil's suggested solution is here:
http://www.keil.com/support/docs/3237.htm

Andy Start a New Thread

--- In l..., Dominic Rath wrote:

> Hello Carsten,
>
> his site explains what he means. "professional system" might not be
the best
> paraphrase, but he's talking about UART implementations that are
able to
> output data at the full baudrate with no additional gaps except for the
> configured start and stop bits. Apparently, the FT232BM is able to
do that,
> while some PC parallel ports (probably best described as "consumer
systems",
> as opposed to "professional systems") might not.
>
> Anyway, it's all on his site, and in this newsgroup's archive.
>
> Regards
>
> Dominic

Thanks Dominic for putting things in perspective. Also, I think you
meant PC serial ports, not parallel ports.

Subsequent to that write up, the defect was demonstrated using CPLD
based UART. This system allows one to arbitrarily vary parameters of
the transmit frame at will. Such a system is can be used to test
compliance of UARTs.

This is what I referred to as "professional system" and to distinguish
it from toy experimentations published by others involving feeding one
LPC UART output into another LPC UART input, or simply using UART to
test compliance of another UART. This is not the way to do compliance
testing.

Nonetheless, if anyone wishes to challenge my findings, and is
prepared to publish their experiment, not hot air, I am happy to take
up the challenge.

Regards,

Jaya Start a New Thread

--- In l..., "jayasooriah" wrote:
> Subsequent to that write up, the defect was demonstrated using CPLD
> based UART. This system allows one to arbitrarily vary parameters
of
> the transmit frame at will. Such a system is can be used to test
> compliance of UARTs.
>
> This is what I referred to as "professional system" and to
distinguish
> it from toy experimentations published by others involving feeding
one
> LPC UART output into another LPC UART input, or simply using UART to
> test compliance of another UART. This is not the way to do
compliance
> testing.
>
> Nonetheless, if anyone wishes to challenge my findings, and is
> prepared to publish their experiment, not hot air, I am happy to
take
> up the challenge.

Jaya,

I don't doubt your system exhibits problematic behaviour. However,
your analysis that the root cause is some undocumented flaw in the
LPC2xxx UART is not correct. If it were correct, others would be able
to reproduce the problem you see.

I've already posted details of tests on this forum and their results.
None of them used the UARTs in a back-to-back mode as you describe,
and oddly enough you're not the only one to use "professional
equipment".

The bottom line is that if you use the UARTs as documented in the
User Manuals, as amended by the errata, they work with no problems.
It's not for others to prove this as you seem to want: it's up to you
who claims they don't work as advertised to provide details of how
and when this can be shown.

All you've put forward to date is that you have a system that doesn't
work as expected. There are many people with working systems that
simply wouldn't work if your claims were true. As I said, this can be
(and has been) shown with some simple experiments.

Brendan. Start a New Thread