---------------------------------
At 08:46 AM 1/9/05 +0000, you wrote: >I've had the UARTs on the LPC21xx LPC22xx
running fine at 115.2k (e.g. >receiving large files with 32 bit CRCs). It just
that the divisor >arrangement means the baud rate @ 12MHz is approx
1% out (with the PLL >multiplying the XTAL by 5 to 60MHz / VPBDIV = 1).
I just wondered >whether the bootloader on the chip gives up if
it can't get an exact >baud rate...
Remember the ISP program on chip doesn't use the PLL
(at least there is no
indication that it does) so a 1% mismatch at the
(pll'd) 60MHz could be a
5% mismatch at 12MHz native clock. You can see the
problem.
Yes I see the problem. I'll have a chat with Philips.
Jane
Robert
" 'Freedom' has no meaning of itself. There are
always restrictions,
be they legal, genetic, or physical. If you don't
believe me, try to
chew a radio signal. "
Kelvin Throop, III
---------------------------------
Yahoo! Groups Links
To
___________________________________________________________
ALL-NEW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
At 08:46 AM 1/9/05 +0000, you wrote: >I've had the UARTs on the LPC21xx LPC22xx
running fine at 115.2k (e.g.
>receiving large files with 32 bit CRCs). It just that the divisor
>arrangement means the baud rate @ 12MHz is approx 1% out (with the PLL
>multiplying the XTAL by 5 to 60MHz / VPBDIV = 1). I just wondered
>whether the bootloader on the chip gives up if it can't get an exact
>baud rate...
Remember the ISP program on chip doesn't use the PLL (at least there is no
indication that it does) so a 1% mismatch at the (pll'd) 60MHz could be a
5% mismatch at 12MHz native clock. You can see the problem.
Robert
" 'Freedom' has no meaning of itself. There are always
restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, III
Reply by jane highland●January 9, 20052005-01-09
Thanks - I'll give it a go.
Best Regards
Jan
--- Alex Holden <> wrote:
---------------------------------
janehighland wrote: > --- In , "lpcarmed" <lpcarmed@g...> wrote: >>one. Also, the lpc21isp.c from Martin Maurer is
much more reliable. > Hi - can you email me a copy...I'd like to
take a look.
--
------------ Alex Holden - http://www.alexholden.net/
------------
If it doesn't work, you're not hitting it with a big
enough hammer
---------------------------------
Yahoo! Groups Links
To
___________________________________________________________
ALL-NEW Yahoo! Messenger - all new features - even more fun!
http://uk.messenger.yahoo.com
Reply by Alex Holden●January 9, 20052005-01-09
janehighland wrote: > --- In , "lpcarmed"
<lpcarmed@g...> wrote:
>>one. Also, the lpc21isp.c from Martin Maurer is much more reliable.
> Hi - can you email me a copy...I'd like to take a look.
--
------------ Alex Holden - http://www.alexholden.net/ ------------
If it doesn't work, you're not hitting it with a big enough hammer
Reply by janehighland●January 9, 20052005-01-09
--- In , "lpcarmed" <lpcarmed@g...> wrote: >
> I had issues with 115K until I replaced the Xtal with a 14.7456MHz
> one. Also, the lpc21isp.c from Martin Maurer is much more reliable.
> Big plus using it you can customize, even to the extent of
> automatically updating the bootlodaer if you wish.
Hi - can you email me a copy...I'd like to take a look.
Thanks
Jane.
>
> --- In , Robert Adsett <subscriptions@a...> wrote: > > At 07:15 PM 1/8/05 +0000, you wrote:
> > >I'll take a look next week on the actual data quality being
received
> > >transmitted at the CPU. I agree with you, from the table in the
user
> > >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so
at
> > >12MHz even though we'll probably have a small percentage
error per
> > >bit, we should still be OK.
> >
> > I think one of us is reading the wrong line. I see 12.288 MHz
> topping out
> > at 38400.
> >
> > What is missing is a description of what is limiting the match so
> that it
> > could be determined for the actual crystal used. I expect it's
a
> divisor
> > issue.
> >
> > If we knew what it was it should be straightforward to figure out which > > baudrates will match (and maybe even switch
crystals to meet
> multiple neeeds).
> >
> > Robert
> >
> >
> > " 'Freedom' has no meaning of itself. There are always
restrictions,
> > be they legal, genetic, or physical. If you don't believe me, try
to
> > chew a radio signal. "
> >
> > Kelvin Throop, III
Reply by janehighland●January 9, 20052005-01-09
--- In , Robert Adsett <subscriptions@a...> wrote: > At 07:15 PM 1/8/05 +0000, you wrote:
> >I'll take a look next week on the actual data quality being
received
> >transmitted at the CPU. I agree with you, from the table in the user
> >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at
> >12MHz even though we'll probably have a small percentage error
per
> >bit, we should still be OK.
>
> I think one of us is reading the wrong line. I see 12.288 MHz topping out > at 38400.
>
> What is missing is a description of what is limiting the match so that it > could be determined for the actual crystal used. I
expect it's a divisor > issue.
>
I've had the UARTs on the LPC21xx LPC22xx running fine at 115.2k (e.g.
receiving large files with 32 bit CRCs). It just that the divisor
arrangement means the baud rate @ 12MHz is approx 1% out (with the PLL
multiplying the XTAL by 5 to 60MHz / VPBDIV = 1). I just wondered
whether the bootloader on the chip gives up if it can't get an exact
baud rate...
Jane
> If we knew what it was it should be
straightforward to figure out which
> baudrates will match (and maybe even switch crystals to meet multiple neeeds). >
> Robert
> " 'Freedom' has no meaning of itself. There are always
restrictions,
> be they legal, genetic, or physical. If you don't believe me, try
to
> chew a radio signal. "
>
> Kelvin Throop, III
Reply by lpcarmed●January 8, 20052005-01-08
I had issues with 115K until I replaced the Xtal with a 14.7456MHz
one. Also, the lpc21isp.c from Martin Maurer is much more reliable.
Big plus using it you can customize, even to the extent of
automatically updating the bootlodaer if you wish.
--- In , Robert Adsett <subscriptions@a...> wrote: > At 07:15 PM 1/8/05 +0000, you wrote:
> >I'll take a look next week on the actual data quality being
received
> >transmitted at the CPU. I agree with you, from the table in the user
> >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at
> >12MHz even though we'll probably have a small percentage error
per
> >bit, we should still be OK.
>
> I think one of us is reading the wrong line. I see 12.288 MHz topping out > at 38400.
>
> What is missing is a description of what is limiting the match so that it > could be determined for the actual crystal used. I
expect it's a divisor > issue.
>
> If we knew what it was it should be straightforward to figure out which
> baudrates will match (and maybe even switch crystals to meet multiple neeeds). >
> Robert
> " 'Freedom' has no meaning of itself. There are always
restrictions,
> be they legal, genetic, or physical. If you don't believe me, try
to
> chew a radio signal. "
>
> Kelvin Throop, III
Reply by Robert Adsett●January 8, 20052005-01-08
At 07:15 PM 1/8/05 +0000, you wrote: >I'll take a look next week on the actual data
quality being received
>transmitted at the CPU. I agree with you, from the table in the user
>manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at
>12MHz even though we'll probably have a small percentage error per
>bit, we should still be OK.
I think one of us is reading the wrong line. I see 12.288 MHz topping out
at 38400.
What is missing is a description of what is limiting the match so that it
could be determined for the actual crystal used. I expect it's a divisor
issue.
If we knew what it was it should be straightforward to figure out which
baudrates will match (and maybe even switch crystals to meet multiple
neeeds).
Robert
" 'Freedom' has no meaning of itself. There are always
restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
Kelvin Throop, III
Reply by janehighland●January 8, 20052005-01-08
--- In , Robert Adsett <subscriptions@a...> wrote: > At 06:48 PM 1/8/05 +0000, you wrote:
> >On the subject of feeling the need to try to program above
> >38400...we've got >200K of Thumb code and thousands of chips to
ISP in
> >the future...I know it will make a difference to our to our PCB
> >subcontractor.
>
> Yep for high volume it will make a big difference. It might be worth your > while to bootstrap to a higher baud rate.
It's something I've been meaning > to work on when I get some time. The idea is the
initial ISP would
> download a a small download program to RAM and run it. It would then set > the serial port to a higher baud rate and use a
binary download
> protocol. The higher might get you a factor of 3 (if you can match rates > closely enough), the reduced overhead of the
binary protocol would get you > a factor of 2. All this minus the actual
programming overhead and the time > to download the initial stub.
>
> Another option in volume might be to get the parts preprogrammed (assuming > they run identical programs). That gets it out of
your subcontractors way > entirely.
>
> For a lot of the stuff I've done functional testing made the programming > time disappear into the noise.
>
> Robert
>
> " 'Freedom' has no meaning of itself. There are always
restrictions,
> be they legal, genetic, or physical. If you don't believe me, try
to
> chew a radio signal. "
>
> Kelvin Throop, III
Thanks Robert.
I'll take a look next week on the actual data quality being received
transmitted at the CPU. I agree with you, from the table in the user
manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at
12MHz even though we'll probably have a small percentage error per
bit, we should still be OK.
Jane
Reply by Robert Adsett●January 8, 20052005-01-08
At 06:48 PM 1/8/05 +0000, you wrote: >On the subject of feeling the need to try to
program above
>38400...we've got >200K of Thumb code and thousands of chips to ISP
in
>the future...I know it will make a difference to our to our PCB
>subcontractor.
Yep for high volume it will make a big difference. It might be worth your
while to bootstrap to a higher baud rate. It's something I've been
meaning
to work on when I get some time. The idea is the initial ISP would
download a a small download program to RAM and run it. It would then set
the serial port to a higher baud rate and use a binary download
protocol. The higher might get you a factor of 3 (if you can match rates
closely enough), the reduced overhead of the binary protocol would get you
a factor of 2. All this minus the actual programming overhead and the time
to download the initial stub.
Another option in volume might be to get the parts preprogrammed (assuming
they run identical programs). That gets it out of your subcontractors way
entirely.
For a lot of the stuff I've done functional testing made the programming
time disappear into the noise.
Robert
" 'Freedom' has no meaning of itself. There are always
restrictions,
be they legal, genetic, or physical. If you don't believe me, try to
chew a radio signal. "
