Iv been working on this problem for the last three days with no avail.
Basically around 80% of the time the first strings/chars sent by the MCU
are garbled.
It is only after the MCU receives something that everything works fine
i.e. I can send or receive with loosing any data.
My code is standard, I don't think
theres any problems with it,debugs fine in keil and I have checked baud
in the UART window and it is as it should be.
I have also checked the buad at the MCU with a scope and it is fine
there also.
LPC2106 -UART, sent data is garbled until something is received by the MCU
Started by ●April 1, 2010
Reply by ●April 1, 20102010-04-01
voltz56 wrote:
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
So you are not seeing anything wrong with the first characters sent? Can
you also verify with the scope, that the line is idle (TTL level high
and EIA level negative) at least one whole character time before the
first character?
--
Timo
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
So you are not seeing anything wrong with the first characters sent? Can
you also verify with the scope, that the line is idle (TTL level high
and EIA level negative) at least one whole character time before the
first character?
--
Timo
Reply by ●April 1, 20102010-04-01
--- In l..., "voltz56" wrote:
>
> Iv been working on this problem for the last three days with no avail.
> Basically around 80% of the time the first strings/chars sent by the MCU
> are garbled.
> It is only after the MCU receives something that everything works fine
> i.e. I can send or receive with loosing any data.
> My code is standard, I don't think
> theres any problems with it,debugs fine in keil and I have checked baud
> in the UART window and it is as it should be.
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
>
Is Hyperterminal involved with this testing? If so, you never want to underestimate the ability of Hyperterminal to embarrass you.
Richard
>
> Iv been working on this problem for the last three days with no avail.
> Basically around 80% of the time the first strings/chars sent by the MCU
> are garbled.
> It is only after the MCU receives something that everything works fine
> i.e. I can send or receive with loosing any data.
> My code is standard, I don't think
> theres any problems with it,debugs fine in keil and I have checked baud
> in the UART window and it is as it should be.
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
>
Is Hyperterminal involved with this testing? If so, you never want to underestimate the ability of Hyperterminal to embarrass you.
Richard
Reply by ●April 1, 20102010-04-01
--- In l..., "voltz56" wrote:
>
> Iv been working on this problem for the last three days with no avail.
> Basically around 80% of the time the first strings/chars sent by the MCU
> are garbled.
> It is only after the MCU receives something that everything works fine
> i.e. I can send or receive with loosing any data.
> My code is standard, I don't think
> theres any problems with it,debugs fine in keil and I have checked baud
> in the UART window and it is as it should be.
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
>
Add UART0_FCR = 0x07; to your init code.
You MUST enable the FIFOs
Richard
>
> Iv been working on this problem for the last three days with no avail.
> Basically around 80% of the time the first strings/chars sent by the MCU
> are garbled.
> It is only after the MCU receives something that everything works fine
> i.e. I can send or receive with loosing any data.
> My code is standard, I don't think
> theres any problems with it,debugs fine in keil and I have checked baud
> in the UART window and it is as it should be.
> I have also checked the buad at the MCU with a scope and it is fine
> there also.
>
Add UART0_FCR = 0x07; to your init code.
You MUST enable the FIFOs
Richard
Reply by ●April 1, 20102010-04-01
--- In l..., Timo wrote:
>
> voltz56 wrote:
> > I have also checked the buad at the MCU with a scope and it is fine
> > there also.
>
> So you are not seeing anything wrong with the first characters sent?
Can
> you also verify with the scope, that the line is idle (TTL level high
> and EIA level negative) at least one whole character time before the
> first character?
>
> --
>
> Timo
>
I took some screen-shots of TX signal after the MCU has been reset.
They look much the same except the for the difference width of the first
pulse.
After a reset when garbled data received
http://img43.imageshack.us/img43/3937/uart0baddata.png
Afer a reset when correct data is received
http://img88.imageshack.us/img88/8260/uart0ok.png
>
> voltz56 wrote:
> > I have also checked the buad at the MCU with a scope and it is fine
> > there also.
>
> So you are not seeing anything wrong with the first characters sent?
Can
> you also verify with the scope, that the line is idle (TTL level high
> and EIA level negative) at least one whole character time before the
> first character?
>
> --
>
> Timo
>
I took some screen-shots of TX signal after the MCU has been reset.
They look much the same except the for the difference width of the first
pulse.
After a reset when garbled data received
http://img43.imageshack.us/img43/3937/uart0baddata.png
Afer a reset when correct data is received
http://img88.imageshack.us/img88/8260/uart0ok.png
Reply by ●April 1, 20102010-04-01
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
> >
> > Iv been working on this problem for the last three days with no avail.
> > Basically around 80% of the time the first strings/chars sent by the MCU
> > are garbled.
> > It is only after the MCU receives something that everything works fine
> > i.e. I can send or receive with loosing any data.
> > My code is standard, I don't think
> > theres any problems with it,debugs fine in keil and I have checked baud
> > in the UART window and it is as it should be.
> > I have also checked the buad at the MCU with a scope and it is fine
> > there also.
> > Add UART0_FCR = 0x07; to your init code.
>
> You MUST enable the FIFOs
>
> Richard
>
I added that but It unfortunately it made no difference,
btw I'm testing with two terminal emulators,
Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
>
> --- In l..., "voltz56" wrote:
> >
> > Iv been working on this problem for the last three days with no avail.
> > Basically around 80% of the time the first strings/chars sent by the MCU
> > are garbled.
> > It is only after the MCU receives something that everything works fine
> > i.e. I can send or receive with loosing any data.
> > My code is standard, I don't think
> > theres any problems with it,debugs fine in keil and I have checked baud
> > in the UART window and it is as it should be.
> > I have also checked the buad at the MCU with a scope and it is fine
> > there also.
> > Add UART0_FCR = 0x07; to your init code.
>
> You MUST enable the FIFOs
>
> Richard
>
I added that but It unfortunately it made no difference,
btw I'm testing with two terminal emulators,
Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
Reply by ●April 1, 20102010-04-01
--- In l..., "voltz56" wrote:
>
I added that but It unfortunately it made no difference,
> btw I'm testing with two terminal emulators,
> Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
>
I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
That PINSEL0 statement would normally be
PINSEL0 |= 0x05;
This prevents disturbing previously set pins.
Right after that, I would substitute
UART0_LCR = 0x83;
for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
Other than that, your code looks like mine.
Richard
>
I added that but It unfortunately it made no difference,
> btw I'm testing with two terminal emulators,
> Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
>
I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
That PINSEL0 statement would normally be
PINSEL0 |= 0x05;
This prevents disturbing previously set pins.
Right after that, I would substitute
UART0_LCR = 0x83;
for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
Other than that, your code looks like mine.
Richard
Reply by ●April 1, 20102010-04-01
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
> >
> I added that but It unfortunately it made no difference,
> > btw I'm testing with two terminal emulators,
> > Indigo and the HyperTerminal if you know of a more reliable
alternative for windows then Id be interested.
> > I use minicom under Linux so no help there. I ALWAYS have trouble
with Hyperterminal. The latest version (cost $) version is a lot
better.
I would test on linux only the cheap serial card I bought from ebay is
not compatible.
> That PINSEL0 statement would normally be
>
> PINSEL0 |= 0x05;
>
> This prevents disturbing previously set pins.
Changed that.
> Right after that, I would substitute
>
> UART0_LCR = 0x83;
>
> for that two statements. There is no sense in setting 5 bit char
widths and then changing it later on.
I had tryed that before and did so again just now but It won't run at
all like this in the debugger or on hardware.
For some reason it alters the divsor latch settings.
http://img52.imageshack.us/img52/6824/uartwindow.jpg
>
> --- In l..., "voltz56" wrote:
> >
> I added that but It unfortunately it made no difference,
> > btw I'm testing with two terminal emulators,
> > Indigo and the HyperTerminal if you know of a more reliable
alternative for windows then Id be interested.
> > I use minicom under Linux so no help there. I ALWAYS have trouble
with Hyperterminal. The latest version (cost $) version is a lot
better.
I would test on linux only the cheap serial card I bought from ebay is
not compatible.
> That PINSEL0 statement would normally be
>
> PINSEL0 |= 0x05;
>
> This prevents disturbing previously set pins.
Changed that.
> Right after that, I would substitute
>
> UART0_LCR = 0x83;
>
> for that two statements. There is no sense in setting 5 bit char
widths and then changing it later on.
I had tryed that before and did so again just now but It won't run at
all like this in the debugger or on hardware.
For some reason it alters the divsor latch settings.
http://img52.imageshack.us/img52/6824/uartwindow.jpg
Reply by ●April 1, 20102010-04-01
--- In l..., "rtstofer" wrote:
>
> --- In l..., "voltz56" wrote:
> >
> I added that but It unfortunately it made no difference,
> > btw I'm testing with two terminal emulators,
> > Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
> > I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
>
> That PINSEL0 statement would normally be
>
> PINSEL0 |= 0x05;
>
> This prevents disturbing previously set pins.
>
> Right after that, I would substitute
>
> UART0_LCR = 0x83;
>
> for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
>
> Other than that, your code looks like mine.
>
> Richard
>
or did you mean to leave UART0_LCR = 0x03 at the end of the function,
if so then then it works fine in the debugger but unfortunately not on the mcu.
>
> --- In l..., "voltz56" wrote:
> >
> I added that but It unfortunately it made no difference,
> > btw I'm testing with two terminal emulators,
> > Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
> > I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
>
> That PINSEL0 statement would normally be
>
> PINSEL0 |= 0x05;
>
> This prevents disturbing previously set pins.
>
> Right after that, I would substitute
>
> UART0_LCR = 0x83;
>
> for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
>
> Other than that, your code looks like mine.
>
> Richard
>
or did you mean to leave UART0_LCR = 0x03 at the end of the function,
if so then then it works fine in the debugger but unfortunately not on the mcu.
Reply by ●April 1, 20102010-04-01
--- In l..., "voltz56" wrote:
> --- In l..., "rtstofer" wrote:
> >
> >
> >
> > --- In l..., "voltz56" wrote:
> > >
> > I added that but It unfortunately it made no difference,
> > > btw I'm testing with two terminal emulators,
> > > Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
> > >
> >
> > I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
> >
> > That PINSEL0 statement would normally be
> >
> > PINSEL0 |= 0x05;
> >
> > This prevents disturbing previously set pins.
> >
> > Right after that, I would substitute
> >
> > UART0_LCR = 0x83;
> >
> > for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
> >
> > Other than that, your code looks like mine.
> >
> > Richard
> > or did you mean to leave UART0_LCR = 0x03 at the end of the function,
> if so then then it works fine in the debugger but unfortunately not on the mcu.
>
This is my setup code (based on CCLK = PCLK):
#define F_OSC 14745600
#define DIVISOR(baudrate) ((F_OSC * 4) / (16 * baudrate))
// Divisor = 32 for 115200 baud
// Divisor = 96 for 38400 baud
// Divisor = 384 for 9600 baud
PINSEL0 |= 0x05; // set Tx0 & RX0 pins
UART0_LCR = 0x83;
UART0_DLM = DIVISOR(115200) >> 8;
UART0_DLL = DIVISOR(115200) & 0xFF;
UART0_LCR = 0x03;
UART0_FCR = 0x07;
Richard
> --- In l..., "rtstofer" wrote:
> >
> >
> >
> > --- In l..., "voltz56" wrote:
> > >
> > I added that but It unfortunately it made no difference,
> > > btw I'm testing with two terminal emulators,
> > > Indigo and the HyperTerminal if you know of a more reliable alternative for windows then Id be interested.
> > >
> >
> > I use minicom under Linux so no help there. I ALWAYS have trouble with Hyperterminal. The latest version (cost $) version is a lot better.
> >
> > That PINSEL0 statement would normally be
> >
> > PINSEL0 |= 0x05;
> >
> > This prevents disturbing previously set pins.
> >
> > Right after that, I would substitute
> >
> > UART0_LCR = 0x83;
> >
> > for that two statements. There is no sense in setting 5 bit char widths and then changing it later on.
> >
> > Other than that, your code looks like mine.
> >
> > Richard
> > or did you mean to leave UART0_LCR = 0x03 at the end of the function,
> if so then then it works fine in the debugger but unfortunately not on the mcu.
>
This is my setup code (based on CCLK = PCLK):
#define F_OSC 14745600
#define DIVISOR(baudrate) ((F_OSC * 4) / (16 * baudrate))
// Divisor = 32 for 115200 baud
// Divisor = 96 for 38400 baud
// Divisor = 384 for 9600 baud
PINSEL0 |= 0x05; // set Tx0 & RX0 pins
UART0_LCR = 0x83;
UART0_DLM = DIVISOR(115200) >> 8;
UART0_DLL = DIVISOR(115200) & 0xFF;
UART0_LCR = 0x03;
UART0_FCR = 0x07;
Richard
