Hi all,
I am using UART0 for serial communication in LPC2101.
When i am testing various baurdrate,9600 is working for me.
But 115200 is not working.This baudrate in needed for my proect.
I am using 12MHZ oscillator frequency.(Fosc).Pll is Enabled and vpbdiv is 0.If
anybody faced
or familiar this issue please share your knowledge.
I am changing various Peripheral frequency values.But still its not working.
Test 1:
CClk = 24,Pclk = 6,PLLCFG = 0x41;
DLL = 2,Divaddvalue = 5,Mulval = 8;
Test 2:
CClk = 36,Pclk = 9,PLLCFG = 0x42;
DLL = 3,Divaddvalue = 5,Mulval = 8;
Test 3:
CClk = 48,Pclk = 12,PLLCFG = 0x23;
DLL = 4,Divaddvalue = 5,Mulval = 8;
Test 4:
CClk = 60,Pclk = 15,PLLCFG = 0x24;
DLL = 6,Divaddvalue = 5,Mulval = 14;
All this testing,Baudrate 115200 is not working.
Anyone please help me...
Thanks,
LPC2101 115200 Baudrate Issues at 12MHZ Oscillator Frequency(Fosc)
Started by ●July 22, 2009
Reply by ●July 22, 20092009-07-22
On Wed, 22 Jul 2009 01:07:46 -0400, you wrote:
>Hi all,
> I am using UART0 for serial communication in LPC2101.
>When i am testing various baurdrate,9600 is working for me.
>But 115200 is not working.This baudrate in needed for my proect.
>
>I am using 12MHZ oscillator frequency.(Fosc).Pll is Enabled and vpbdiv is 0.If anybody faced
>or familiar this issue please share your knowledge.
>
>I am changing various Peripheral frequency values.But still its not working.
>
>Test 1:
>
> CClk = 24,Pclk = 6,PLLCFG = 0x41;
> DLL = 2,Divaddvalue = 5,Mulval = 8;
>
>Test 2:
>
> CClk = 36,Pclk = 9,PLLCFG = 0x42;
> DLL = 3,Divaddvalue = 5,Mulval = 8;
>Test 3:
>
> CClk = 48,Pclk = 12,PLLCFG = 0x23;
> DLL = 4,Divaddvalue = 5,Mulval = 8;
>Test 4:
>
> CClk = 60,Pclk = 15,PLLCFG = 0x24;
> DLL = 6,Divaddvalue = 5,Mulval = 14;
>
>All this testing,Baudrate 115200 is not working.
>Anyone please help me...
>
Send 0x55 bytes from the transmitter and look at the output on a scope - this will tell you
whether the rate is getting set correctly.
>Hi all,
> I am using UART0 for serial communication in LPC2101.
>When i am testing various baurdrate,9600 is working for me.
>But 115200 is not working.This baudrate in needed for my proect.
>
>I am using 12MHZ oscillator frequency.(Fosc).Pll is Enabled and vpbdiv is 0.If anybody faced
>or familiar this issue please share your knowledge.
>
>I am changing various Peripheral frequency values.But still its not working.
>
>Test 1:
>
> CClk = 24,Pclk = 6,PLLCFG = 0x41;
> DLL = 2,Divaddvalue = 5,Mulval = 8;
>
>Test 2:
>
> CClk = 36,Pclk = 9,PLLCFG = 0x42;
> DLL = 3,Divaddvalue = 5,Mulval = 8;
>Test 3:
>
> CClk = 48,Pclk = 12,PLLCFG = 0x23;
> DLL = 4,Divaddvalue = 5,Mulval = 8;
>Test 4:
>
> CClk = 60,Pclk = 15,PLLCFG = 0x24;
> DLL = 6,Divaddvalue = 5,Mulval = 14;
>
>All this testing,Baudrate 115200 is not working.
>Anyone please help me...
>
Send 0x55 bytes from the transmitter and look at the output on a scope - this will tell you
whether the rate is getting set correctly.
Reply by ●July 22, 20092009-07-22
I had the same problems at one time, found it to be that the baudrate error was
just a bit too much for the PC.
For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
That's assuming that is the problem you have, it may not be.
For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
That's assuming that is the problem you have, it may not be.
Reply by ●July 23, 20092009-07-23
Dear,
you have to configure U0DLL as follows:
#define Pclk 12000000
#define VPBDIV 4
#define baudrate 11520
U0DLL = Pclk /(16*VPBDIV * baudrate)
regards
tripathi
> On Wed, 22 Jul 2009 01:07:46 -0400, you wrote:
>
>>Hi all,
>> I am using UART0 for serial communication in LPC2101.
>>When i am testing various baurdrate,9600 is working for me.
>>But 115200 is not working.This baudrate in needed for my proect.
>>
>>I am using 12MHZ oscillator frequency.(Fosc).Pll is Enabled and vpbdiv is
>> 0.If anybody faced
>>or familiar this issue please share your knowledge.
>>
>>I am changing various Peripheral frequency values.But still its not
>> working.
>>
>>Test 1:
>>
>> CClk = 24,Pclk = 6,PLLCFG = 0x41;
>> DLL = 2,Divaddvalue = 5,Mulval = 8;
>>
>>Test 2:
>>
>> CClk = 36,Pclk = 9,PLLCFG = 0x42;
>> DLL = 3,Divaddvalue = 5,Mulval = 8;
>>Test 3:
>>
>> CClk = 48,Pclk = 12,PLLCFG = 0x23;
>> DLL = 4,Divaddvalue = 5,Mulval = 8;
>>Test 4:
>>
>> CClk = 60,Pclk = 15,PLLCFG = 0x24;
>> DLL = 6,Divaddvalue = 5,Mulval = 14;
>>
>>All this testing,Baudrate 115200 is not working.
>>Anyone please help me...
>> Send 0x55 bytes from the transmitter and look at the output on a scope -
> this will tell you
> whether the rate is getting set correctly.
>
you have to configure U0DLL as follows:
#define Pclk 12000000
#define VPBDIV 4
#define baudrate 11520
U0DLL = Pclk /(16*VPBDIV * baudrate)
regards
tripathi
> On Wed, 22 Jul 2009 01:07:46 -0400, you wrote:
>
>>Hi all,
>> I am using UART0 for serial communication in LPC2101.
>>When i am testing various baurdrate,9600 is working for me.
>>But 115200 is not working.This baudrate in needed for my proect.
>>
>>I am using 12MHZ oscillator frequency.(Fosc).Pll is Enabled and vpbdiv is
>> 0.If anybody faced
>>or familiar this issue please share your knowledge.
>>
>>I am changing various Peripheral frequency values.But still its not
>> working.
>>
>>Test 1:
>>
>> CClk = 24,Pclk = 6,PLLCFG = 0x41;
>> DLL = 2,Divaddvalue = 5,Mulval = 8;
>>
>>Test 2:
>>
>> CClk = 36,Pclk = 9,PLLCFG = 0x42;
>> DLL = 3,Divaddvalue = 5,Mulval = 8;
>>Test 3:
>>
>> CClk = 48,Pclk = 12,PLLCFG = 0x23;
>> DLL = 4,Divaddvalue = 5,Mulval = 8;
>>Test 4:
>>
>> CClk = 60,Pclk = 15,PLLCFG = 0x24;
>> DLL = 6,Divaddvalue = 5,Mulval = 14;
>>
>>All this testing,Baudrate 115200 is not working.
>>Anyone please help me...
>> Send 0x55 bytes from the transmitter and look at the output on a scope -
> this will tell you
> whether the rate is getting set correctly.
>
Reply by ●July 25, 20092009-07-25
--- In l..., "cm296pip" wrote:
> I had the same problems at one time, found it to be that the baudrate error was just a bit too much for the PC.
>
> For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
>
> That's assuming that is the problem you have, it may not be.
>
1.73% error - too high for some situations with 115.2Kbaud.
Did you look at using a different crystal or using the fractional baud rate divider register?
> I had the same problems at one time, found it to be that the baudrate error was just a bit too much for the PC.
>
> For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
>
> That's assuming that is the problem you have, it may not be.
>
1.73% error - too high for some situations with 115.2Kbaud.
Did you look at using a different crystal or using the fractional baud rate divider register?
Reply by ●July 26, 20092009-07-26
--- In l..., "stevech11" wrote:
>
> --- In l..., "cm296pip" wrote:
> >
> >
> > I had the same problems at one time, found it to be that the baudrate error was just a bit too much for the PC.
> >
> > For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
> >
> > That's assuming that is the problem you have, it may not be.
> > 1.73% error - too high for some situations with 115.2Kbaud.
> Did you look at using a different crystal or using the fractional baud rate divider register?
>
Please explain, how can 1.73% be too high. we are talking start bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The potential error is multiplied by 10, that would be 17.3%. Now lets assume the the counterpart is also 1.73% off but for the argument sake this one is too slow, the other one 1.73% too fast. This adds another 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was off by 10%, which would be more than to be expected, the total error adds up to 44.6% for the last bit. That is still good enough to decode the bit correctly. Usually a PC serial interface has no noticeable deviation from a standard target frequency such as 115200. In such as case even 3% off on the MCU side would be working (though very risky).
Something else must be wrong here.
Cheers, Bob
>
> --- In l..., "cm296pip" wrote:
> >
> >
> > I had the same problems at one time, found it to be that the baudrate error was just a bit too much for the PC.
> >
> > For accurate buad rates it's best to have xtal frequencies of say 14.7456MHz, 7.3728MHz etc
> >
> > That's assuming that is the problem you have, it may not be.
> > 1.73% error - too high for some situations with 115.2Kbaud.
> Did you look at using a different crystal or using the fractional baud rate divider register?
>
Please explain, how can 1.73% be too high. we are talking start bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The potential error is multiplied by 10, that would be 17.3%. Now lets assume the the counterpart is also 1.73% off but for the argument sake this one is too slow, the other one 1.73% too fast. This adds another 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was off by 10%, which would be more than to be expected, the total error adds up to 44.6% for the last bit. That is still good enough to decode the bit correctly. Usually a PC serial interface has no noticeable deviation from a standard target frequency such as 115200. In such as case even 3% off on the MCU side would be working (though very risky).
Something else must be wrong here.
Cheers, Bob
Reply by ●July 26, 20092009-07-26
> Please explain, how can 1.73% be too high. we are
talking start bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The
potential error is multiplied by 10, that would be 17.3%. Now lets assume the
the counterpart is also 1.73% off but for the argument sake this one is too
slow, the other one 1.73% too fast. This adds another 10x1.73% adds up to 34.6%.
Now let's assume the center of the bit was off by 10%, which would be more
than to be expected, the total error adds up to 44.6% for the last bit. That is
still good enough to decode the bit correctly. Usually a PC serial interface has
no noticeable deviation from a standard target frequency such as 115200. In such
as case even 3% off on the MCU side would be working (though very risky).
> Something else must be wrong here.
Yes it could well be something else wrong ..
But I too had only a 1 to 2% error on baudrate, BUT the problem only showed itself when many bytes were sent down the UART link without any gaps/pauses between each byte, which kinda pointed towards the receiving UART not doing a timing reset on each start bit - maybe the uarts only start from scratch when it see's a fresh start bit after a pause between bytes?
> Something else must be wrong here.
Yes it could well be something else wrong ..
But I too had only a 1 to 2% error on baudrate, BUT the problem only showed itself when many bytes were sent down the UART link without any gaps/pauses between each byte, which kinda pointed towards the receiving UART not doing a timing reset on each start bit - maybe the uarts only start from scratch when it see's a fresh start bit after a pause between bytes?
Reply by ●July 27, 20092009-07-27
--- In l..., "cm296pip" wrote:
> > Please explain, how can 1.73% be too high. we are talking start bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The potential error is multiplied by 10, that would be 17.3%. Now lets assume the the counterpart is also 1.73% off but for the argument sake this one is too slow, the other one 1.73% too fast. This adds another 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was off by 10%, which would be more than to be expected, the total error adds up to 44.6% for the last bit. That is still good enough to decode the bit correctly. Usually a PC serial interface has no noticeable deviation from a standard target frequency such as 115200. In such as case even 3% off on the MCU side would be working (though very risky).
> > Something else must be wrong here.
>
> Yes it could well be something else wrong ..
>
> But I too had only a 1 to 2% error on baudrate, BUT the problem only showed itself when many bytes were sent down the UART link without any gaps/pauses between each byte, which kinda pointed towards the receiving UART not doing a timing reset on each start bit - maybe the uarts only start from scratch when it see's a fresh start bit after a pause between bytes?
>
That's an interesting approach and I wonder if in such a case any baudrate error would lead to a transmission error eventually!? It is my understanding that in an async. communication every startbit is used to get the center of the bit again.
May be it is missing the falling edge of the next start bit?
In general an accumulated baudrate error, both sender and receiver combined of <= 3% should absolutely work and the PC should be fairly accurate with the baudrate afaik.
Having said all that, there is definitely no harm with the LPC2101 to used the 14.756 MHz except for a minimal loss in performance versus 60 MHz with the 5x PLL and 12 MHz crystal.
Just my 2 cents, Bob
> > Please explain, how can 1.73% be too high. we are talking start bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The potential error is multiplied by 10, that would be 17.3%. Now lets assume the the counterpart is also 1.73% off but for the argument sake this one is too slow, the other one 1.73% too fast. This adds another 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was off by 10%, which would be more than to be expected, the total error adds up to 44.6% for the last bit. That is still good enough to decode the bit correctly. Usually a PC serial interface has no noticeable deviation from a standard target frequency such as 115200. In such as case even 3% off on the MCU side would be working (though very risky).
> > Something else must be wrong here.
>
> Yes it could well be something else wrong ..
>
> But I too had only a 1 to 2% error on baudrate, BUT the problem only showed itself when many bytes were sent down the UART link without any gaps/pauses between each byte, which kinda pointed towards the receiving UART not doing a timing reset on each start bit - maybe the uarts only start from scratch when it see's a fresh start bit after a pause between bytes?
>
That's an interesting approach and I wonder if in such a case any baudrate error would lead to a transmission error eventually!? It is my understanding that in an async. communication every startbit is used to get the center of the bit again.
May be it is missing the falling edge of the next start bit?
In general an accumulated baudrate error, both sender and receiver combined of <= 3% should absolutely work and the PC should be fairly accurate with the baudrate afaik.
Having said all that, there is definitely no harm with the LPC2101 to used the 14.756 MHz except for a minimal loss in performance versus 60 MHz with the 5x PLL and 12 MHz crystal.
Just my 2 cents, Bob
Reply by ●July 27, 20092009-07-27
lpc2100_fan wrote:
>
>
> --- In l... ,
> "cm296pip" wrote:
> >
> >
> > > Please explain, how can 1.73% be too high. we are talking start
> bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The
> potential error is multiplied by 10, that would be 17.3%. Now lets
> assume the the counterpart is also 1.73% off but for the argument sake
> this one is too slow, the other one 1.73% too fast. This adds another
> 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was
> off by 10%, which would be more than to be expected, the total error
> adds up to 44.6% for the last bit. That is still good enough to decode
> the bit correctly. Usually a PC serial interface has no noticeable
> deviation from a standard target frequency such as 115200. In such as
> case even 3% off on the MCU side would be working (though very risky).
> > > Something else must be wrong here.
> >
> > Yes it could well be something else wrong ..
> >
> > But I too had only a 1 to 2% error on baudrate, BUT the problem only
> showed itself when many bytes were sent down the UART link without any
> gaps/pauses between each byte, which kinda pointed towards the
> receiving UART not doing a timing reset on each start bit - maybe the
> uarts only start from scratch when it see's a fresh start bit after a
> pause between bytes?
> > That's an interesting approach and I wonder if in such a case any
> baudrate error would lead to a transmission error eventually!? It is
> my understanding that in an async. communication every startbit is
> used to get the center of the bit again.
>
> May be it is missing the falling edge of the next start bit?
>
> In general an accumulated baudrate error, both sender and receiver
> combined of <= 3% should absolutely work and the PC should be fairly
> accurate with the baudrate afaik.
> Having said all that, there is definitely no harm with the LPC2101 to
> used the 14.756 MHz except for a minimal loss in performance versus 60
> MHz with the 5x PLL and 12 MHz crystal.
>
> Just my 2 cents, Bob
Isn't the math here wrong?
If the bit time is 10uS and the actual baud clock period is 10.173uS,
the two systems see total times of 10x10uS0uS and 10x10.173uS 101.73uS and the error remains 1.73%.
High school math.
And for what its worth, I've used baud clocks up to 5% out without
problem, but it depends on how the receiver samples the incoming signal.
Jonathan Masters
>
>
> --- In l... ,
> "cm296pip" wrote:
> >
> >
> > > Please explain, how can 1.73% be too high. we are talking start
> bit, 8 data bit and usually 1 Stop bit. so that is 10 bit. The
> potential error is multiplied by 10, that would be 17.3%. Now lets
> assume the the counterpart is also 1.73% off but for the argument sake
> this one is too slow, the other one 1.73% too fast. This adds another
> 10x1.73% adds up to 34.6%. Now let's assume the center of the bit was
> off by 10%, which would be more than to be expected, the total error
> adds up to 44.6% for the last bit. That is still good enough to decode
> the bit correctly. Usually a PC serial interface has no noticeable
> deviation from a standard target frequency such as 115200. In such as
> case even 3% off on the MCU side would be working (though very risky).
> > > Something else must be wrong here.
> >
> > Yes it could well be something else wrong ..
> >
> > But I too had only a 1 to 2% error on baudrate, BUT the problem only
> showed itself when many bytes were sent down the UART link without any
> gaps/pauses between each byte, which kinda pointed towards the
> receiving UART not doing a timing reset on each start bit - maybe the
> uarts only start from scratch when it see's a fresh start bit after a
> pause between bytes?
> > That's an interesting approach and I wonder if in such a case any
> baudrate error would lead to a transmission error eventually!? It is
> my understanding that in an async. communication every startbit is
> used to get the center of the bit again.
>
> May be it is missing the falling edge of the next start bit?
>
> In general an accumulated baudrate error, both sender and receiver
> combined of <= 3% should absolutely work and the PC should be fairly
> accurate with the baudrate afaik.
> Having said all that, there is definitely no harm with the LPC2101 to
> used the 14.756 MHz except for a minimal loss in performance versus 60
> MHz with the 5x PLL and 12 MHz crystal.
>
> Just my 2 cents, Bob
Isn't the math here wrong?
If the bit time is 10uS and the actual baud clock period is 10.173uS,
the two systems see total times of 10x10uS0uS and 10x10.173uS 101.73uS and the error remains 1.73%.
High school math.
And for what its worth, I've used baud clocks up to 5% out without
problem, but it depends on how the receiver samples the incoming signal.
Jonathan Masters
Reply by ●July 27, 20092009-07-27
We have had problems with 115200 working with 12MHz osc with some(about 10%)
of our boards too We are using LPC2368 and LPC2388 in all of new designs. We
never messed with the factional control of the UARTs, never had a need to.
We just when down to a slower baud. However, it came back up again for ISP
programming in production. Flashmagic's windows program was barfing on
verify on some of the boards, even if we slowed the baud. We fixed the
problem with ISP by using the command line version and setting the baud to
112500, the LPC 23xxs are running at 72MHz so the divider is a even 320.
That error of 1.73% at 115200 does stack up on some systems with high data
transfers.
Two more cents,
Michael Freeman
Principal Design Engineer
Update Systems, Inc.
of our boards too We are using LPC2368 and LPC2388 in all of new designs. We
never messed with the factional control of the UARTs, never had a need to.
We just when down to a slower baud. However, it came back up again for ISP
programming in production. Flashmagic's windows program was barfing on
verify on some of the boards, even if we slowed the baud. We fixed the
problem with ISP by using the command line version and setting the baud to
112500, the LPC 23xxs are running at 72MHz so the divider is a even 320.
That error of 1.73% at 115200 does stack up on some systems with high data
transfers.
Two more cents,
Michael Freeman
Principal Design Engineer
Update Systems, Inc.
