Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Thread

Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by jp_thrower

This post is a followup to my original post number 9985.

When U1DLL = 0x01, U1DLM=0x00, and is used with the fractional divisor
U1FDR to set the baudrate, the device properly transmits at the
assigned baudrate, but does not receive at the assigned baudrate.

I have conducted a series of elementary tests using the frequency
117187 and a PC com port terminal set to 115200 baud.  The program
(genesis from Keil's example to give credit) transmits characters from
the LPC2148 to the PC, reads characters from the PC, and echos them
back to the PC.

The frequency 117187 can be acquired with multiple settings using a 12
MHz clock, or 15 MHz PCLK:

UART_baudrate = PCLK/(16*(16*U1DLM+U1DLL)) * (MulVal/(MulVal+DivAddVal))

U1DLL, MulVal, DivAddVal, Equation
0x01    0x1        0x7    117187 = 15000000/16/(1)*(1/8)
0x02    0x1        0x3    117187 = 15000000/16/(2)*(1/4)
0x03    0x9        0xF    117187 = 15000000/16/(3)*(9/24)

In each case, the tranmit of characters worked fine, but in the case
of 0x01, the receive characters were garbled.

I do have set U1FCR |= 0x01, which the manual says is required for
correct operation.

Is there an errata on this?  Does UART0 have the same issue?
Is there a way around this that I don't know?
This is important to me because I have to work with 500000 baud
signal, and U1DLL=1 seems like my only option without swapping crystals.

JP

Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by jp_thrower

Thanks for the suggestion.
Unfortunately, the result is same as before.
I'm looking at what effect doubling the PCLK will do to the board so
that I can use U1DLL=0x02.

JP

--- In lpc2000@yahoogroups.com, "Martin Maurer" <mailingliste@c...> wrote:
Show quoted textHide quoted text
>
> Hello,
> 
> > I do have set U1FCR |= 0x01, which the manual says is required for
> > correct operation.
> 
> Perhaps try U1FCR = 0x01 ! U1FCR seems to be a WriteOnly (WO) register, 
> perhaps it is a problem, because |= is read-modify-write.
> 
> Regards,
> 
>         Martin
>

Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by rtstofer

You baud rate error is on the order of 1.7%.  That the PC will 
accept it is to its credit.  That the LPC won't is not a surprise.  
Assuming your PCLK is as accurate as you hope - have you checked it 
with a frequency counter?

The examples in the user manual have errors around 0.06%

Further, you may not be sending EXACTLY 115200 from the PC.

This is not to say I have any idea about how to resolve the issue.  
I just noted the huge difference in % error versus the user manual.

Richard



--- In lpc2000@yahoogroups.com, "jp_thrower" <jp_thrower@y...> wrote:
>
> This post is a followup to my original post number 9985.
> 
> When U1DLL = 0x01, U1DLM=0x00, and is used with the fractional 
divisor
> U1FDR to set the baudrate, the device properly transmits at the
> assigned baudrate, but does not receive at the assigned baudrate.
> 
> I have conducted a series of elementary tests using the frequency
> 117187 and a PC com port terminal set to 115200 baud.  The program
> (genesis from Keil's example to give credit) transmits characters 
from
> the LPC2148 to the PC, reads characters from the PC, and echos them
> back to the PC.
> 
> The frequency 117187 can be acquired with multiple settings using 
a 12
> MHz clock, or 15 MHz PCLK:
> 
> UART_baudrate = PCLK/(16*(16*U1DLM+U1DLL)) * (MulVal/
(MulVal+DivAddVal))
> 
> U1DLL, MulVal, DivAddVal, Equation
> 0x01    0x1        0x7    117187 = 15000000/16/(1)*(1/8)
> 0x02    0x1        0x3    117187 = 15000000/16/(2)*(1/4)
> 0x03    0x9        0xF    117187 = 15000000/16/(3)*(9/24)
> 
> In each case, the tranmit of characters worked fine, but in the 
case
> of 0x01, the receive characters were garbled.
> 
> I do have set U1FCR |= 0x01, which the manual says is required for
> correct operation.
> 
> Is there an errata on this?  Does UART0 have the same issue?
> Is there a way around this that I don't know?
> This is important to me because I have to work with 500000 baud
> signal, and U1DLL=1 seems like my only option without swapping 
crystals.
Show quoted textHide quoted text
> 
> JP
>

Re: [lpc2000] Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by Joel Winarske

JP,

I'm curious if this might help in any way.

http://groups.yahoo.com/group/lpc2000/files/Tools/lpc2fdcalc.exe

You enter your peripheral clock, desired baud, and the number of results to 
list.  It goes through all possible combinations.  It will list from the 
lowest % error to the largest.


Joel
Show quoted textHide quoted text
> Thanks for the suggestion.
> Unfortunately, the result is same as before.
> I'm looking at what effect doubling the PCLK will do to the board so
> that I can use U1DLL=0x02.
>
> JP

Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by jp_thrower

I actually used lpc2fdcalc to get the experimental values.  
It's a good tool.

JP

--- In lpc2000@yahoogroups.com, "Joel Winarske" <joelw@i...> wrote:
>
> JP,
> 
> I'm curious if this might help in any way.
> 
> http://groups.yahoo.com/group/lpc2000/files/Tools/lpc2fdcalc.exe
> 
> You enter your peripheral clock, desired baud, and the number of
results to 
> list.  It goes through all possible combinations.  It will list from
the 
Show quoted textHide quoted text
> lowest % error to the largest.
> 
> 
> Joel
> 
> 
> 
> > Thanks for the suggestion.
> > Unfortunately, the result is same as before.
> > I'm looking at what effect doubling the PCLK will do to the board so
> > that I can use U1DLL=0x02.
> >
> > JP
>

Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by jp_thrower

The baud rate may be off by 1.7 %, however the PC still communicated
correctly when I used the exact same baud rate, 117187, from other
register configurations (as reported U1DLL= 0x02, 0x03).  

Furthermore, the behavior of the receiver not working when U1DLL=0x01
is consistent with screwy behavior I got at 500000 baud.  I reported
on that in posting # 9985.

I have worked around my issue by doubling the PCLK (it was going at
1/4 CCLK) and using a U1DLL=0x02.  In this particular case it doesn't
seem to cause too many additional issues.  Regardless, the phenomenon
seems like an error in intended operation.

JP

--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
Show quoted textHide quoted text
>
> 
> You baud rate error is on the order of 1.7%.  That the PC will 
> accept it is to its credit.  That the LPC won't is not a surprise.  
> Assuming your PCLK is as accurate as you hope - have you checked it 
> with a frequency counter?
> 
> The examples in the user manual have errors around 0.06%
> 
> Further, you may not be sending EXACTLY 115200 from the PC.
> 
> This is not to say I have any idea about how to resolve the issue.  
> I just noted the huge difference in % error versus the user manual.
> 
> Richard
> 
> 
> 
> --- In lpc2000@yahoogroups.com, "jp_thrower" <jp_thrower@y...> wrote:
> >
> > This post is a followup to my original post number 9985.
> > 
> > When U1DLL = 0x01, U1DLM=0x00, and is used with the fractional 
> divisor
> > U1FDR to set the baudrate, the device properly transmits at the
> > assigned baudrate, but does not receive at the assigned baudrate.
> > 
> > I have conducted a series of elementary tests using the frequency
> > 117187 and a PC com port terminal set to 115200 baud.  The program
> > (genesis from Keil's example to give credit) transmits characters 
> from
> > the LPC2148 to the PC, reads characters from the PC, and echos them
> > back to the PC.
> > 
> > The frequency 117187 can be acquired with multiple settings using 
> a 12
> > MHz clock, or 15 MHz PCLK:
> > 
> > UART_baudrate = PCLK/(16*(16*U1DLM+U1DLL)) * (MulVal/
> (MulVal+DivAddVal))
> > 
> > U1DLL, MulVal, DivAddVal, Equation
> > 0x01    0x1        0x7    117187 = 15000000/16/(1)*(1/8)
> > 0x02    0x1        0x3    117187 = 15000000/16/(2)*(1/4)
> > 0x03    0x9        0xF    117187 = 15000000/16/(3)*(9/24)
> > 
> > In each case, the tranmit of characters worked fine, but in the 
> case
> > of 0x01, the receive characters were garbled.
> > 
> > I do have set U1FCR |= 0x01, which the manual says is required for
> > correct operation.
> > 
> > Is there an errata on this?  Does UART0 have the same issue?
> > Is there a way around this that I don't know?
> > This is important to me because I have to work with 500000 baud
> > signal, and U1DLL=1 seems like my only option without swapping 
> crystals.
> > 
> > JP
> >
>

Re: [lpc2000] Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by Tom Walsh

jp_thrower wrote:

>The baud rate may be off by 1.7 %, however the PC still communicated
>correctly when I used the exact same baud rate, 117187, from other
>register configurations (as reported U1DLL= 0x02, 0x03).  
>
>  
>
I thought that the acceptable degree of error is somewhere around 0.5%?  
1.7% seems to be very high...

Let's see, 2400 - 1.7% == 2359buad, nope, I would not expect that to 
work!  I've gotten errors while being as much as 10 points of at 2400, 
e.g. 2390baud.

Where do you see that a 1.7% deviation is acceptable?  It has been a 
while since I've played with software uarts but I tried to keep within 
0.25% of error.


TomW


>Furthermore, the behavior of the receiver not working when U1DLL=0x01
>is consistent with screwy behavior I got at 500000 baud.  I reported
>on that in posting # 9985.
>
>I have worked around my issue by doubling the PCLK (it was going at
>1/4 CCLK) and using a U1DLL=0x02.  In this particular case it doesn't
>seem to cause too many additional issues.  Regardless, the phenomenon
>seems like an error in intended operation.
>
>JP
>
>--- In lpc2000@yahoogroups.com, "rtstofer" <rstofer@p...> wrote:
>  
>
>>You baud rate error is on the order of 1.7%.  That the PC will 
>>accept it is to its credit.  That the LPC won't is not a surprise.  
>>Assuming your PCLK is as accurate as you hope - have you checked it 
>>with a frequency counter?
>>
>>The examples in the user manual have errors around 0.06%
>>
>>Further, you may not be sending EXACTLY 115200 from the PC.
>>
>>This is not to say I have any idea about how to resolve the issue.  
>>I just noted the huge difference in % error versus the user manual.
>>
>>Richard
>>
>>
>>
>>--- In lpc2000@yahoogroups.com, "jp_thrower" <jp_thrower@y...> wrote:
>>    
>>
>>>This post is a followup to my original post number 9985.
>>>
>>>When U1DLL = 0x01, U1DLM=0x00, and is used with the fractional 
>>>      
>>>
>>divisor
>>    
>>
>>>U1FDR to set the baudrate, the device properly transmits at the
>>>assigned baudrate, but does not receive at the assigned baudrate.
>>>
>>>I have conducted a series of elementary tests using the frequency
>>>117187 and a PC com port terminal set to 115200 baud.  The program
>>>(genesis from Keil's example to give credit) transmits characters 
>>>      
>>>
>>from
>>    
>>
>>>the LPC2148 to the PC, reads characters from the PC, and echos them
>>>back to the PC.
>>>
>>>The frequency 117187 can be acquired with multiple settings using 
>>>      
>>>
>>a 12
>>    
>>
>>>MHz clock, or 15 MHz PCLK:
>>>
>>>UART_baudrate = PCLK/(16*(16*U1DLM+U1DLL)) * (MulVal/
>>>      
>>>
>>(MulVal+DivAddVal))
>>    
>>
>>>U1DLL, MulVal, DivAddVal, Equation
>>>0x01    0x1        0x7    117187 = 15000000/16/(1)*(1/8)
>>>0x02    0x1        0x3    117187 = 15000000/16/(2)*(1/4)
>>>0x03    0x9        0xF    117187 = 15000000/16/(3)*(9/24)
>>>
>>>In each case, the tranmit of characters worked fine, but in the 
>>>      
>>>
>>case
>>    
>>
>>>of 0x01, the receive characters were garbled.
>>>
>>>I do have set U1FCR |= 0x01, which the manual says is required for
>>>correct operation.
>>>
>>>Is there an errata on this?  Does UART0 have the same issue?
>>>Is there a way around this that I don't know?
>>>This is important to me because I have to work with 500000 baud
>>>signal, and U1DLL=1 seems like my only option without swapping 
>>>      
>>>
>>crystals.
>>    
>>
>>>JP
>>>
>>>      
>>>
>
>
>
>
>
>
>
>
> 
>Yahoo! Groups Links
>
>
>
> 
>
>
>
>  
>


-- 
Tom Walsh - WN3L - Embedded Systems Consultant
http://openhardware.net, http://cyberiansoftware.com
"Windows? No thanks, I have work to do..."
----------------------------------------------------

Re: Confirmed: U1DLL = 0x01 does not recieve on LPC2148 using fractional divisor

2005-11-03 by jp_thrower

1.7% means that the 11th bit of each character is off by about 20% 
(1.017 ^ 11).  This is not unusable given that my signals are clean. 
Still, your expectations may be right for many UARTs in noisy
environments.  I really don't know what most software UARTS do.  What
I do know is that the 1.7% is irrelevant because the chip performs
inconsistently given the same baudrate.

The experiment I detailed was chosen to point out how the same
baudrate performs differently based on register settings.  

Furthermore, my initial issue utilized a 500,000 baudrate exactly and
still didn't work.  Only when I doubled the PCLK so that my U1DLL
could be 0x02 instead of 0x01 did the system start operating correctly.

JP

--- In lpc2000@yahoogroups.com, Tom Walsh <tom@o...> wrote:
>
> jp_thrower wrote:
> 
> >The baud rate may be off by 1.7 %, however the PC still communicated
> >correctly when I used the exact same baud rate, 117187, from other
> >register configurations (as reported U1DLL= 0x02, 0x03).  
> >
> >  
> >
> I thought that the acceptable degree of error is somewhere around
0.5%?  
Show quoted textHide quoted text
> 1.7% seems to be very high...
> 
> Let's see, 2400 - 1.7% == 2359buad, nope, I would not expect that to 
> work!  I've gotten errors while being as much as 10 points of at 2400, 
> e.g. 2390baud.
> 
> Where do you see that a 1.7% deviation is acceptable?  It has been a 
> while since I've played with software uarts but I tried to keep within 
> 0.25% of error.
> 
> 
> TomW
> 
>

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.