jayasooriah wrote:
> System is LPC2292; XTAL = 14.7456 MHz; PLL disabled;
MAM disabled;
> VPBDIV = 1; UART = 8-data, 1-stop, no-parity, FIFO enabled.
>
> Symptom are that for certain (low) baud rates, UART silently drops
> characters on Rx channel when saturated. There is no indication of
> this in the LSR and none of the error bits (OE|PE|FE|BI|RXFE) are set
> when this happens.
>
> It appears that UART logic is failing to copy RSR (Rx Shift Register)
> to RBR (Rx Buffer Register) for certain baud rates when a further
> character follows immediately behind.
>
> More specifically, at 1200 baud, when a sequence of characters is
> transmitted 8.33 ms apart, all characters but the last one are dropped
> by the UART and the driver is unaware it has lost characters.
>
> [Test program to demonstrate bug available on request -- please drop
> me an email.]
>
> The work around for this anomaly appears to have been implemented in
> Philips Boot Loader that works under boot loader conditions.
>
> It appears there is no real work around when UART is used in an
> environment where Rx and Tx channels are subject to saturation.
>
> Does anyone else know of this bug and/or its work around?
>
> Jaya
I hate to throw things but I am going to have to throw something on your
fire too ....FUEL! My interrupt coms routines are very robust and cope
with extreme baud rates....well at least in the high-speed end. I ran a
quick couple of tests on my system which runs from a baud-rate friendly
22.1184MHz rock and I didn't experience any problems whatsoever. When I
finally dropped down to 300 baud then weird things started to happen,
the system definitely locks up after a short while of sending characters.
Now this may just be a bug in my driver but it is strange indeed that it
didn't happen at any higher baud rate and had you not said anything I
would never of tested this at such a low speed.
The drivers are identical enough on both uarts so that I will test this
on the second uart and monitor it from the first. Hopefully I will find
some time tonight to do this and I will post my findings then.
*Peter*
Re: LPC2000 UART drops characters silently?
Started by ●July 14, 2006
Reply by ●July 15, 20062006-07-15
Reply by ●July 15, 20062006-07-15
Hi, Mr Jaya,
Sorry, unable to duplicate your problem...
Created a very very simple Arm7 code and simple VB testcode as
attached.
- LPC2103@18.432Mhz, Talking to my Dell Dimension, 2.8Ghz CPU
- Baud 300, 8, N, 1
- Test sending about 30 characters at a time
- Test 300+ loops and none failed.
I'm happy with my LPC2103 chip here so far, works very fine....
I believe VB MsCOMM just throw everything to the 16C550 FIFO and
all bytes should be packed back-to-back.
I can re-code the test program in MsVC++ 6.0 but I believe it will
generate same good result. You can cut+paste the codes. VB MSComm
setting as "300,8,n,1" VB Timer interval as 1000mS
Please help checking:
- Is my ARM7 UART setting same as yours??
- If you are using FPGA to generate UART bitstream, could you try
feeding that bit stream to your PC??
- Could it be your ARM7 auto-baud routine is a bit out/inaccurate
at lower frequencies??
- Or could it be your board is faulty?? You seem having only one
set.
=================================
#include "LPC21xx.H"
#define CpuKHz 18432
void InitUart (long Baud);
void InitUart (long Baud) {
PINSEL0 &= ~0x0000000f;
PINSEL0 |= 0x00000005;
U0LCR = 0x83;
U0DLL = (((CpuKHz*1000)/(Baud*16))&0xff);
U0DLM = ((CpuKHz*1000)/(Baud*16))>>8;
U0LCR = 0x03;
U0FCR = 0x47;
}
int main (void) {
long i;
InitUart(300);
while (1) {
if (U0LSR & 0x01) {
i=U0RBR;
U0THR = i;
}
}
}
Option Explicit
Dim Run As Integer
Dim StUart, TstCount, loopcount, failcount As Integer
Dim SentStr As String
' This subroutine throw message onto the text box only
Private Sub DisplayMsg(Msg As String)
Dim Str As String
Str = TextBox.Text
If Len(Str) > 4096 Then Str = Mid(Str, 1024)
Str = Str & Msg
TextBox.Text = Str
TextBox.SelStart = 4096
End Sub
Private Sub BtnRUn_Click()
If BtnRUn.Caption = "Run" Then
Run = True
BtnRUn.Caption = "Stop"
Else
Run = False
BtnRUn.Caption = "Run"
End If
End Sub
Private Sub Form_Load()
Run = False
StUart = 0
DisplayMsg "Testing Uart" & vbCrLf
MSComm.PortOpen = True
End Sub
Private Sub Timer1_Timer()
Dim Str As String
If Run = False Then
Exit Sub
End If
Select Case StUart
Case 0:
SentStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZ " & TstCount
DisplayMsg "Sending:" & SentStr & vbCrLf
MSComm.Output = SentStr
TstCount = TstCount + 1
loopcount = loopcount + 1
StUart = 1
Case 1:
Str = MSComm.Input
DisplayMsg "Received:" & Str & vbCrLf
If SentStr = Str Then
DisplayMsg "Matched" & vbCrLf
Else
DisplayMsg "*****Failed*******" & Str & vbCrLf
failcount = failcount + 1
End If
Label1.Caption = "Pass:" & loopcount
Label2.Caption = "fail:" & failcount
StUart = 0
End Select
End Sub
=================================--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > Sorry, I cannot get the full picture...
> >
> > Does that mean??
> > - The UART working fine at higher baud rate and having bugs at
> > lower baud rate
>
> Yes.
>
> > - And difference in the 2 settings (Higher and lower baud rates)
> > is only the baud rate prescaler value.
>
> Yes.
>
> >
> > I'm only interested in if there is any bugs at commonly used
9600 to
> > 115200, at about 60MHz PCLK/CPUCLK
>
> It does not seem to matter if PLL is enabled and CPU clock is 4
times
> XTAL clock. The problem manifests itself in the same way.
>
> > (One way to verify that bug could be using another uC or PC to
tap
> > the same RX line)
>
> The waveforms look okay -- not much to diagnost between a one- and
> two-character traces on the CRO.
>
> When driven by CPLD based UART, and an extra stop bit inserted
between
> the charactes, the problem goes away, with all else constant.
>
> >
> > Regards
>
> In the operational situation where Tx channel is used while
receiving
> characters (for XON/XOFF handshake), no errors were seen for
standard
> baud rates from 921600 down to 230400.
>
> The error rates start going up from 115200 down to 19200 and then
the
> problem is deterministic from there on -- one character at a time
> always works and two character at a time always fails.
>
> It was hard to get data from the client's operational system, so I
> recreated the same situation with my own (verified) code.
>
> For the controlled situation (experiment just reading a line
without
> echoing, and printing the line on receiving EOL), it no errors are
> seen at 19200 baud and above.
>
> The above for 14.7456 MHz crystal, and data coming from FTDI 232BM
> chip running off 6 MHz crystal.
>
> Jaya
>
Sorry, unable to duplicate your problem...
Created a very very simple Arm7 code and simple VB testcode as
attached.
- LPC2103@18.432Mhz, Talking to my Dell Dimension, 2.8Ghz CPU
- Baud 300, 8, N, 1
- Test sending about 30 characters at a time
- Test 300+ loops and none failed.
I'm happy with my LPC2103 chip here so far, works very fine....
I believe VB MsCOMM just throw everything to the 16C550 FIFO and
all bytes should be packed back-to-back.
I can re-code the test program in MsVC++ 6.0 but I believe it will
generate same good result. You can cut+paste the codes. VB MSComm
setting as "300,8,n,1" VB Timer interval as 1000mS
Please help checking:
- Is my ARM7 UART setting same as yours??
- If you are using FPGA to generate UART bitstream, could you try
feeding that bit stream to your PC??
- Could it be your ARM7 auto-baud routine is a bit out/inaccurate
at lower frequencies??
- Or could it be your board is faulty?? You seem having only one
set.
=================================
#include "LPC21xx.H"
#define CpuKHz 18432
void InitUart (long Baud);
void InitUart (long Baud) {
PINSEL0 &= ~0x0000000f;
PINSEL0 |= 0x00000005;
U0LCR = 0x83;
U0DLL = (((CpuKHz*1000)/(Baud*16))&0xff);
U0DLM = ((CpuKHz*1000)/(Baud*16))>>8;
U0LCR = 0x03;
U0FCR = 0x47;
}
int main (void) {
long i;
InitUart(300);
while (1) {
if (U0LSR & 0x01) {
i=U0RBR;
U0THR = i;
}
}
}
Option Explicit
Dim Run As Integer
Dim StUart, TstCount, loopcount, failcount As Integer
Dim SentStr As String
' This subroutine throw message onto the text box only
Private Sub DisplayMsg(Msg As String)
Dim Str As String
Str = TextBox.Text
If Len(Str) > 4096 Then Str = Mid(Str, 1024)
Str = Str & Msg
TextBox.Text = Str
TextBox.SelStart = 4096
End Sub
Private Sub BtnRUn_Click()
If BtnRUn.Caption = "Run" Then
Run = True
BtnRUn.Caption = "Stop"
Else
Run = False
BtnRUn.Caption = "Run"
End If
End Sub
Private Sub Form_Load()
Run = False
StUart = 0
DisplayMsg "Testing Uart" & vbCrLf
MSComm.PortOpen = True
End Sub
Private Sub Timer1_Timer()
Dim Str As String
If Run = False Then
Exit Sub
End If
Select Case StUart
Case 0:
SentStr = "ABCDEFGHIJKLMNOPQRSTUVWXYZ " & TstCount
DisplayMsg "Sending:" & SentStr & vbCrLf
MSComm.Output = SentStr
TstCount = TstCount + 1
loopcount = loopcount + 1
StUart = 1
Case 1:
Str = MSComm.Input
DisplayMsg "Received:" & Str & vbCrLf
If SentStr = Str Then
DisplayMsg "Matched" & vbCrLf
Else
DisplayMsg "*****Failed*******" & Str & vbCrLf
failcount = failcount + 1
End If
Label1.Caption = "Pass:" & loopcount
Label2.Caption = "fail:" & failcount
StUart = 0
End Select
End Sub
=================================--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > Sorry, I cannot get the full picture...
> >
> > Does that mean??
> > - The UART working fine at higher baud rate and having bugs at
> > lower baud rate
>
> Yes.
>
> > - And difference in the 2 settings (Higher and lower baud rates)
> > is only the baud rate prescaler value.
>
> Yes.
>
> >
> > I'm only interested in if there is any bugs at commonly used
9600 to
> > 115200, at about 60MHz PCLK/CPUCLK
>
> It does not seem to matter if PLL is enabled and CPU clock is 4
times
> XTAL clock. The problem manifests itself in the same way.
>
> > (One way to verify that bug could be using another uC or PC to
tap
> > the same RX line)
>
> The waveforms look okay -- not much to diagnost between a one- and
> two-character traces on the CRO.
>
> When driven by CPLD based UART, and an extra stop bit inserted
between
> the charactes, the problem goes away, with all else constant.
>
> >
> > Regards
>
> In the operational situation where Tx channel is used while
receiving
> characters (for XON/XOFF handshake), no errors were seen for
standard
> baud rates from 921600 down to 230400.
>
> The error rates start going up from 115200 down to 19200 and then
the
> problem is deterministic from there on -- one character at a time
> always works and two character at a time always fails.
>
> It was hard to get data from the client's operational system, so I
> recreated the same situation with my own (verified) code.
>
> For the controlled situation (experiment just reading a line
without
> echoing, and printing the line on receiving EOL), it no errors are
> seen at 19200 baud and above.
>
> The above for 14.7456 MHz crystal, and data coming from FTDI 232BM
> chip running off 6 MHz crystal.
>
> Jaya
>
Reply by ●July 15, 20062006-07-15
--- In l..., Peter Jakacki wrote:
> I hate to throw things but I am going to have to throw something on
your
> fire too ....FUEL! My interrupt coms routines are very robust and cope
> with extreme baud rates....well at least in the high-speed end. I ran a
> quick couple of tests on my system which runs from a baud-rate friendly
> 22.1184MHz rock and I didn't experience any problems whatsoever. When I
> finally dropped down to 300 baud then weird things started to happen,
> the system definitely locks up after a short while of sending
characters.
>
> Now this may just be a bug in my driver but it is strange indeed
that it
> didn't happen at any higher baud rate and had you not said anything I
> would never of tested this at such a low speed.
>
> The drivers are identical enough on both uarts so that I will test this
> on the second uart and monitor it from the first. Hopefully I will find
> some time tonight to do this and I will post my findings then.
I find that if I saturate the UART with 8-data, 1-stop bit frames
while it is set to 8-data, 2-stop bits, it drops characters without
reporting errors. This same mechanism is probably the culprit.
Another thing I found is that my own download utility (that talks to
ISP) works reliably at high baud rates from 230400 down to 9600, but
at 4800 strange things start to happen.
After a while, it starts dropping character on a line by line basis,
and with the number of characters dropped increasing along the way.
Extra newlines are echowed back when this happens, and it terminates
with RESEND rather than OK as shown below.
Given noone is waiting on me to resolve this, I am moving on to some
other chores at the moment ... but would be still intersted in what
you find.
Jaya
Synchronized
OK
14746
OK
U 23130
0
W 1073742336 3640
0
J*/"?Y2CPG^4D\)_E(/"?Y1SPG^4L;Z"X%/"?Y1#PG^7_____________
J________.````,P````",:#C`3I#X@``D^7\___J`3J#X@`@H.,"*8+B
J``"2Y?S__^H!$:#C`AJ!X@``D>7\___J`0"@X=OP*>,`T*#AU_`IXP#0
JH.'1\"GC`-"@X=+P*>,`T*#AT_`IXP#0H.&``$#BW_`IXP#0H.$#B
J`>"/XA[_+^$!.`$Y`3H`\#GX$4@#(0%@06"J(8%@52&!8/[G```/X0Y`
J3^"0`%3C#O"@`7P`5.,.\*`!;`!4XP[PH`$.$*#A`>"/XA[_+^$`\#[[
JW><``````.#`1L!&P$;`1L!&P$8`M0``>$?`1@_@H.$0_R_A`>"/XA[_
J+^$`O JG4(4T``C!9,%F@$CDT`!.P:3Z48`(P`@"I,`\)W\`/!G^@0<`/!6_2`<
J"[`PO0TCZ><,(^?G````P1_@`0``@`#`_W\`X/]_\+5?1D9&P+2,L``@
J`Y`"D`&0`)``\/+X`"@`T.O@`/`;_(!&("@`V>/@`P8`(!X.@T8`)0#P
$/P$'``H`-K6X%I&,Q@2`AL&DT8!-1X.@T0!+>_=`/``_`<<`"@`VL3@
,Q@;!@`E'@Y%10_:`/#T^P0<`"@`VK;@,Q@;!AX.$"-;&6A&`37$5$5%
[]L`+`#:J>``\.'[,Q@;!@0<'@X`*`#:GN``+@#0F>``\,7\!!P**`#0
D>``+P#1@^!:1@`J`-!]X`$O`-%VX`(O9M`#+TK0!"\XT`4O'M``+QG1
`/"K_`0<.BB:T%XF`#P1?D#D``H`]$`F@`J!=$`(`RP&+R81J-&
\+T!F`#PKOGUYW0YT)&!"H1T6A&`WP;!@&30WP!FAL$&D.#?!L"
&D/#?!I#`2,!D@"YW,B`Y+1YT!&`B@*T6I&$WP;!@*34WP"F!L$
&$,"D``GN.=S(,#*Q310$8$*`_1:D81?%-\"0,;`1E#DWS2?!L"
$T/+&`&3`2,`DP`([WG82+3YT)&`BK@T6A&`WP;`P*30WP"FAL!
7905
RESEND
> I hate to throw things but I am going to have to throw something on
your
> fire too ....FUEL! My interrupt coms routines are very robust and cope
> with extreme baud rates....well at least in the high-speed end. I ran a
> quick couple of tests on my system which runs from a baud-rate friendly
> 22.1184MHz rock and I didn't experience any problems whatsoever. When I
> finally dropped down to 300 baud then weird things started to happen,
> the system definitely locks up after a short while of sending
characters.
>
> Now this may just be a bug in my driver but it is strange indeed
that it
> didn't happen at any higher baud rate and had you not said anything I
> would never of tested this at such a low speed.
>
> The drivers are identical enough on both uarts so that I will test this
> on the second uart and monitor it from the first. Hopefully I will find
> some time tonight to do this and I will post my findings then.
I find that if I saturate the UART with 8-data, 1-stop bit frames
while it is set to 8-data, 2-stop bits, it drops characters without
reporting errors. This same mechanism is probably the culprit.
Another thing I found is that my own download utility (that talks to
ISP) works reliably at high baud rates from 230400 down to 9600, but
at 4800 strange things start to happen.
After a while, it starts dropping character on a line by line basis,
and with the number of characters dropped increasing along the way.
Extra newlines are echowed back when this happens, and it terminates
with RESEND rather than OK as shown below.
Given noone is waiting on me to resolve this, I am moving on to some
other chores at the moment ... but would be still intersted in what
you find.
Jaya
Synchronized
OK
14746
OK
U 23130
0
W 1073742336 3640
0
J*/"?Y2CPG^4D\)_E(/"?Y1SPG^4L;Z"X%/"?Y1#PG^7_____________
J________.````,P````",:#C`3I#X@``D^7\___J`3J#X@`@H.,"*8+B
J``"2Y?S__^H!$:#C`AJ!X@``D>7\___J`0"@X=OP*>,`T*#AU_`IXP#0
JH.'1\"GC`-"@X=+P*>,`T*#AT_`IXP#0H.&``$#BW_`IXP#0H.$#B
J`>"/XA[_+^$!.`$Y`3H`\#GX$4@#(0%@06"J(8%@52&!8/[G```/X0Y`
J3^"0`%3C#O"@`7P`5.,.\*`!;`!4XP[PH`$.$*#A`>"/XA[_+^$`\#[[
JW><``````.#`1L!&P$;`1L!&P$8`M0``>$?`1@_@H.$0_R_A`>"/XA[_
J+^$`O JG4(4T``C!9,%F@$CDT`!.P:3Z48`(P`@"I,`\)W\`/!G^@0<`/!6_2`<
J"[`PO0TCZ><,(^?G````P1_@`0``@`#`_W\`X/]_\+5?1D9&P+2,L``@
J`Y`"D`&0`)``\/+X`"@`T.O@`/`;_(!&("@`V>/@`P8`(!X.@T8`)0#P
$/P$'``H`-K6X%I&,Q@2`AL&DT8!-1X.@T0!+>_=`/``_`<<`"@`VL3@
,Q@;!@`E'@Y%10_:`/#T^P0<`"@`VK;@,Q@;!AX.$"-;&6A&`37$5$5%
[]L`+`#:J>``\.'[,Q@;!@0<'@X`*`#:GN``+@#0F>``\,7\!!P**`#0
D>``+P#1@^!:1@`J`-!]X`$O`-%VX`(O9M`#+TK0!"\XT`4O'M``+QG1
`/"K_`0<.BB:T%XF`#P1?D#D``H`]$`F@`J!=$`(`RP&+R81J-&
\+T!F`#PKOGUYW0YT)&!"H1T6A&`WP;!@&30WP!FAL$&D.#?!L"
&D/#?!I#`2,!D@"YW,B`Y+1YT!&`B@*T6I&$WP;!@*34WP"F!L$
&$,"D``GN.=S(,#*Q310$8$*`_1:D81?%-\"0,;`1E#DWS2?!L"
$T/+&`&3`2,`DP`([WG82+3YT)&`BK@T6A&`WP;`P*30WP"FAL!
7905
RESEND
Reply by ●July 15, 20062006-07-15
--- In l..., "unity0724" wrote:
>
> Hi, Mr Jaya,
> Sorry, unable to duplicate your problem...
>
> Created a very very simple Arm7 code and simple VB testcode as
> attached.
> - LPC2103@..., Talking to my Dell Dimension, 2.8Ghz CPU
> - Baud 300, 8, N, 1
> - Test sending about 30 characters at a time
> - Test 300+ loops and none failed.
> I'm happy with my LPC2103 chip here so far, works very fine....
>
> I believe VB MsCOMM just throw everything to the 16C550 FIFO and
> all bytes should be packed back-to-back.
> I can re-code the test program in MsVC++ 6.0 but I believe it will
> generate same good result. You can cut+paste the codes. VB MSComm
> setting as "300,8,n,1" VB Timer interval as 1000mS
Looks like LPC2103 does not have this problem.
> Please help checking:
> - Is my ARM7 UART setting same as yours??
Yes.
> - If you are using FPGA to generate UART bitstream, could you try
> feeding that bit stream to your PC??
It is being generated by FTDI's FT213BM dongle. It seems to have no
problems at whatever speed with AVR boards I have.
> - Could it be your ARM7 auto-baud routine is a bit out/inaccurate
> at lower frequencies??
Auto-baud simply sets the speed, and if it is wrong, I expect error
bits to be set on line status register. I am losing data but there is
no evidence of anything abnormal in the line status register.
Also I tried a few precompiled speeds at the ends and the result is
the same.
> - Or could it be your board is faulty?? You seem having only one
> set.
Unfortunately with only one dongle and one board, I cannot really rule
this out completely except to say that flakey dongle or board surely
would set error bits in the line status register.
Jaya
>
> Hi, Mr Jaya,
> Sorry, unable to duplicate your problem...
>
> Created a very very simple Arm7 code and simple VB testcode as
> attached.
> - LPC2103@..., Talking to my Dell Dimension, 2.8Ghz CPU
> - Baud 300, 8, N, 1
> - Test sending about 30 characters at a time
> - Test 300+ loops and none failed.
> I'm happy with my LPC2103 chip here so far, works very fine....
>
> I believe VB MsCOMM just throw everything to the 16C550 FIFO and
> all bytes should be packed back-to-back.
> I can re-code the test program in MsVC++ 6.0 but I believe it will
> generate same good result. You can cut+paste the codes. VB MSComm
> setting as "300,8,n,1" VB Timer interval as 1000mS
Looks like LPC2103 does not have this problem.
> Please help checking:
> - Is my ARM7 UART setting same as yours??
Yes.
> - If you are using FPGA to generate UART bitstream, could you try
> feeding that bit stream to your PC??
It is being generated by FTDI's FT213BM dongle. It seems to have no
problems at whatever speed with AVR boards I have.
> - Could it be your ARM7 auto-baud routine is a bit out/inaccurate
> at lower frequencies??
Auto-baud simply sets the speed, and if it is wrong, I expect error
bits to be set on line status register. I am losing data but there is
no evidence of anything abnormal in the line status register.
Also I tried a few precompiled speeds at the ends and the result is
the same.
> - Or could it be your board is faulty?? You seem having only one
> set.
Unfortunately with only one dongle and one board, I cannot really rule
this out completely except to say that flakey dongle or board surely
would set error bits in the line status register.
Jaya
Reply by ●July 15, 20062006-07-15
OK, Following chips tested:
- LPC2103, 18.432Mhz, PLL-Off,
- LPC2134, 18.432Mhz, PLL-Off, Date Code 0619
- LPC2124, 18.432Mhz, PLL x3, Date Code 0510
Sorry, all could not duplicate your problem.
I'm very sure my VB program is sending Baud 300,8,N,1
I do not have any LQFP144 here. All projects here are small.
Regards
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > Hi, Mr Jaya,
> > Sorry, unable to duplicate your problem...
> >
> > Created a very very simple Arm7 code and simple VB testcode as
> > attached.
> > - LPC2103@, Talking to my Dell Dimension, 2.8Ghz CPU
> > - Baud 300, 8, N, 1
> > - Test sending about 30 characters at a time
> > - Test 300+ loops and none failed.
> > I'm happy with my LPC2103 chip here so far, works very fine....
> >
> > I believe VB MsCOMM just throw everything to the 16C550 FIFO and
> > all bytes should be packed back-to-back.
> > I can re-code the test program in MsVC++ 6.0 but I believe it
will
> > generate same good result. You can cut+paste the codes. VB
MSComm
> > setting as "300,8,n,1" VB Timer interval as 1000mS
>
> Looks like LPC2103 does not have this problem.
>
> > Please help checking:
> > - Is my ARM7 UART setting same as yours??
>
> Yes.
>
> > - If you are using FPGA to generate UART bitstream, could you try
> > feeding that bit stream to your PC??
>
> It is being generated by FTDI's FT213BM dongle. It seems to have
no
> problems at whatever speed with AVR boards I have.
>
> > - Could it be your ARM7 auto-baud routine is a bit
out/inaccurate
> > at lower frequencies??
>
> Auto-baud simply sets the speed, and if it is wrong, I expect error
> bits to be set on line status register. I am losing data but
there is
> no evidence of anything abnormal in the line status register.
>
> Also I tried a few precompiled speeds at the ends and the result is
> the same.
>
> > - Or could it be your board is faulty?? You seem having only one
> > set.
>
> Unfortunately with only one dongle and one board, I cannot really
rule
> this out completely except to say that flakey dongle or board
surely
> would set error bits in the line status register.
>
> Jaya
>
- LPC2103, 18.432Mhz, PLL-Off,
- LPC2134, 18.432Mhz, PLL-Off, Date Code 0619
- LPC2124, 18.432Mhz, PLL x3, Date Code 0510
Sorry, all could not duplicate your problem.
I'm very sure my VB program is sending Baud 300,8,N,1
I do not have any LQFP144 here. All projects here are small.
Regards
--- In l..., "jayasooriah"
wrote:
>
> --- In l..., "unity0724" wrote:
> >
> > Hi, Mr Jaya,
> > Sorry, unable to duplicate your problem...
> >
> > Created a very very simple Arm7 code and simple VB testcode as
> > attached.
> > - LPC2103@, Talking to my Dell Dimension, 2.8Ghz CPU
> > - Baud 300, 8, N, 1
> > - Test sending about 30 characters at a time
> > - Test 300+ loops and none failed.
> > I'm happy with my LPC2103 chip here so far, works very fine....
> >
> > I believe VB MsCOMM just throw everything to the 16C550 FIFO and
> > all bytes should be packed back-to-back.
> > I can re-code the test program in MsVC++ 6.0 but I believe it
will
> > generate same good result. You can cut+paste the codes. VB
MSComm
> > setting as "300,8,n,1" VB Timer interval as 1000mS
>
> Looks like LPC2103 does not have this problem.
>
> > Please help checking:
> > - Is my ARM7 UART setting same as yours??
>
> Yes.
>
> > - If you are using FPGA to generate UART bitstream, could you try
> > feeding that bit stream to your PC??
>
> It is being generated by FTDI's FT213BM dongle. It seems to have
no
> problems at whatever speed with AVR boards I have.
>
> > - Could it be your ARM7 auto-baud routine is a bit
out/inaccurate
> > at lower frequencies??
>
> Auto-baud simply sets the speed, and if it is wrong, I expect error
> bits to be set on line status register. I am losing data but
there is
> no evidence of anything abnormal in the line status register.
>
> Also I tried a few precompiled speeds at the ends and the result is
> the same.
>
> > - Or could it be your board is faulty?? You seem having only one
> > set.
>
> Unfortunately with only one dongle and one board, I cannot really
rule
> this out completely except to say that flakey dongle or board
surely
> would set error bits in the line status register.
>
> Jaya
>
Reply by ●July 15, 20062006-07-15
--- In l..., "unity0724" wrote:
>
> OK, Following chips tested:
> - LPC2103, 18.432Mhz, PLL-Off,
> - LPC2134, 18.432Mhz, PLL-Off, Date Code 0619
> - LPC2124, 18.432Mhz, PLL x3, Date Code 0510
>
> Sorry, all could not duplicate your problem.
> I'm very sure my VB program is sending Baud 300,8,N,1
> I do not have any LQFP144 here. All projects here are small.
> Regards
I looked at the output from a PC and found that it was really hard to
push it to saturation limits as well as I could with FTDI chip.
So I decided to force saturation by setting the host computer to
8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
Both with no parity.
If you now try to do the experiment I suggested (I have the hex build
now available at the web site), you may be able repeat the problem
with just standard PC serial port.
The hex-file with auto-baud can be downloaded from here:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
To run the experiment, load this program using your favourite ISP
flash loader, set the baudrate of your terminal emulator to whatever
you want, reset the target, and hit the space character.
On successful baud rate negotiation, you will get the "#" prompt.
Now type a few characters followed by new line. Whatever you typed
will be echoed back. Repeat this at 300 baud and you will notice
characters are missing.
On my LPC2292/0510 characters dropouts are deterministic and reproducible.
The UART read routine checks and returns 0 if there were errors, and
the output routine will print this using escape sequence "%00". You
will find that characters are missed but you see any escapes sequences.
Regards,
Jaya
PS: You can also try the ISP loading experiment (in the page I
referred to above) at slow speeds, but my guess is that you will not
see the problem unless your system is able to push the channel to its
limit.
>
> OK, Following chips tested:
> - LPC2103, 18.432Mhz, PLL-Off,
> - LPC2134, 18.432Mhz, PLL-Off, Date Code 0619
> - LPC2124, 18.432Mhz, PLL x3, Date Code 0510
>
> Sorry, all could not duplicate your problem.
> I'm very sure my VB program is sending Baud 300,8,N,1
> I do not have any LQFP144 here. All projects here are small.
> Regards
I looked at the output from a PC and found that it was really hard to
push it to saturation limits as well as I could with FTDI chip.
So I decided to force saturation by setting the host computer to
8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
Both with no parity.
If you now try to do the experiment I suggested (I have the hex build
now available at the web site), you may be able repeat the problem
with just standard PC serial port.
The hex-file with auto-baud can be downloaded from here:
http://www.cse.unsw.edu.au/~jayas/esdk/lpc2/limitations.html
To run the experiment, load this program using your favourite ISP
flash loader, set the baudrate of your terminal emulator to whatever
you want, reset the target, and hit the space character.
On successful baud rate negotiation, you will get the "#" prompt.
Now type a few characters followed by new line. Whatever you typed
will be echoed back. Repeat this at 300 baud and you will notice
characters are missing.
On my LPC2292/0510 characters dropouts are deterministic and reproducible.
The UART read routine checks and returns 0 if there were errors, and
the output routine will print this using escape sequence "%00". You
will find that characters are missed but you see any escapes sequences.
Regards,
Jaya
PS: You can also try the ISP loading experiment (in the page I
referred to above) at slow speeds, but my guess is that you will not
see the problem unless your system is able to push the channel to its
limit.
Reply by ●July 15, 20062006-07-15
--- In l..., "jayasooriah"
wrote:
> Another thing I found is that my own download utility (that talks
to
> ISP) works reliably at high baud rates from 230400 down to 9600,
but
> at 4800 strange things start to happen.
>
> After a while, it starts dropping character on a line by line
basis,
> and with the number of characters dropped increasing along the
way.
> Extra newlines are echowed back when this happens, and it
terminates
> with RESEND rather than OK as shown below.
>
> Given noone is waiting on me to resolve this, I am moving on to
some
> other chores at the moment ... but would be still intersted in what
> you find.
>
Just to ensure I got this straight:
- you have a system with problems at low bit rates
- you claim the problem is an internal design flaw with the UART
- you can't provide any evidence for this, other than the system you
have that doesn't work as expected
- nobody else has come forward to confirm the behaviour you've seen:
on the contrary at least two people have said they can't reproduce it
- you're now moving on to other things, as noone is waiting on you
to resolve this
Hmmmmm....
My own opinion is that there are plenty of other, and in my view
more likely, causes for the behaviour you've seen. Can I suggest
that if you make a claim in future that you provide some real
evidence for it?
By the way, on an asynchronous interface it's perfectly valid for a
UART not to report any problems at mismatched speeds: if for example
the line is low when it's expecting a stop bit, it'll just report
the previous 8 bits as data, whatever they are.
Brendan.
wrote:
> Another thing I found is that my own download utility (that talks
to
> ISP) works reliably at high baud rates from 230400 down to 9600,
but
> at 4800 strange things start to happen.
>
> After a while, it starts dropping character on a line by line
basis,
> and with the number of characters dropped increasing along the
way.
> Extra newlines are echowed back when this happens, and it
terminates
> with RESEND rather than OK as shown below.
>
> Given noone is waiting on me to resolve this, I am moving on to
some
> other chores at the moment ... but would be still intersted in what
> you find.
>
Just to ensure I got this straight:
- you have a system with problems at low bit rates
- you claim the problem is an internal design flaw with the UART
- you can't provide any evidence for this, other than the system you
have that doesn't work as expected
- nobody else has come forward to confirm the behaviour you've seen:
on the contrary at least two people have said they can't reproduce it
- you're now moving on to other things, as noone is waiting on you
to resolve this
Hmmmmm....
My own opinion is that there are plenty of other, and in my view
more likely, causes for the behaviour you've seen. Can I suggest
that if you make a claim in future that you provide some real
evidence for it?
By the way, on an asynchronous interface it's perfectly valid for a
UART not to report any problems at mismatched speeds: if for example
the line is low when it's expecting a stop bit, it'll just report
the previous 8 bits as data, whatever they are.
Brendan.
Reply by ●July 15, 20062006-07-15
--- In l..., "jayasooriah"
> So I decided to force saturation by setting the host computer to
> 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> Both with no parity.
Umm..Sorry..it sounds logical but I failed to understand the logic..
> So I decided to force saturation by setting the host computer to
> 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> Both with no parity.
Umm..Sorry..it sounds logical but I failed to understand the logic..
Reply by ●July 15, 20062006-07-15
--- In l..., "unity0724" wrote:
>
> --- In l..., "jayasooriah"
> > So I decided to force saturation by setting the host computer to
> > 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> > Both with no parity.
>
> Umm..Sorry..it sounds logical but I failed to understand the logic..
>
When LPC UART is set to 8-data 2-stop bits, it expects two stop bits
after the character before the next one arrives.
When host UART is set to 8-data 1-stop bits, and it sends data quickly
enough, there will be only 1-stop bit plus delays, which is less than
2-stop bit delay.
On receiving the two characters with less than 2-stop bits after the
first character, the LPC UART should detect this and report framing error.
It appears UART0 on LPC2292/0510 does not. Instead it discard the
first character silently.
For the benefit of the others who are seeing such UART problems and
wondering why it is not reproducible, I found that you are less likely
to see the problem if your driver is interrupt driven.
It appears that this problem occurs more when the LSR register is
constantly being polled. Thus it makes sense that when you are
polling, you are more likely to see this error at low baud rates.
Hope this helps.
Jaya
PS: I also found out how and why the Philips Boot Loader misses
characters when run at low baud rates -- the Boot Loader tries to
handle both and end of line sequences, but gets it wrong.
>
> --- In l..., "jayasooriah"
> > So I decided to force saturation by setting the host computer to
> > 8-data and 1-stop bits, and the LPC2292 to 8-data and 2-stop bits.
> > Both with no parity.
>
> Umm..Sorry..it sounds logical but I failed to understand the logic..
>
When LPC UART is set to 8-data 2-stop bits, it expects two stop bits
after the character before the next one arrives.
When host UART is set to 8-data 1-stop bits, and it sends data quickly
enough, there will be only 1-stop bit plus delays, which is less than
2-stop bit delay.
On receiving the two characters with less than 2-stop bits after the
first character, the LPC UART should detect this and report framing error.
It appears UART0 on LPC2292/0510 does not. Instead it discard the
first character silently.
For the benefit of the others who are seeing such UART problems and
wondering why it is not reproducible, I found that you are less likely
to see the problem if your driver is interrupt driven.
It appears that this problem occurs more when the LSR register is
constantly being polled. Thus it makes sense that when you are
polling, you are more likely to see this error at low baud rates.
Hope this helps.
Jaya
PS: I also found out how and why the Philips Boot Loader misses
characters when run at low baud rates -- the Boot Loader tries to
handle both and end of line sequences, but gets it wrong.
Reply by ●July 15, 20062006-07-15
--- In l..., "brendanmurphy37"
wrote:
> Just to ensure I got this straight:
>
> - you have a system with problems at low bit rates
> - you claim the problem is an internal design flaw with the UART
> - you can't provide any evidence for this, other than the system you
> have that doesn't work as expected
> - nobody else has come forward to confirm the behaviour you've seen:
> on the contrary at least two people have said they can't reproduce it
> - you're now moving on to other things, as noone is waiting on you
> to resolve this
>
> Hmmmmm....
Hmmmm.... Indeed. No you have not got it right Brendan. You never
seem to be able to get some things right. I doubt anyone can ever
explain such things to you enough.
Stop behaving as if you are desparate for the Starfish customer of the
year award.
Jaya
wrote:
> Just to ensure I got this straight:
>
> - you have a system with problems at low bit rates
> - you claim the problem is an internal design flaw with the UART
> - you can't provide any evidence for this, other than the system you
> have that doesn't work as expected
> - nobody else has come forward to confirm the behaviour you've seen:
> on the contrary at least two people have said they can't reproduce it
> - you're now moving on to other things, as noone is waiting on you
> to resolve this
>
> Hmmmmm....
Hmmmm.... Indeed. No you have not got it right Brendan. You never
seem to be able to get some things right. I doubt anyone can ever
explain such things to you enough.
Stop behaving as if you are desparate for the Starfish customer of the
year award.
Jaya
