Hi abrpbay12,
Thanks for the comment, I think you and Richard are right. I am using a bastardized Crossworks project from a different project, and the ISR handling has a couple levels of indirection that I think just pushed it over the edge in terms of timing.

I was expecting to have to address a higher clock speed, but thought that a simple pass thru shouldn't tax the system. However, it looks like it was.

In the other thread, I note that I bumped it up to use the 14.7456Mhz oscillator on my board, and things cleared up (though I'm losing the CrossConnect JTAG when I engage the external oscillator...but that is a different problem I'll work with them).

Thanks very much for your response...

--- In l..., "abrpbay12" wrote:
>
> Hello goodgodgivemeanaliasalready
>
> I just recently read your message...
>
> I assume somewhere in your code you have modified bits 9 and 8 of PCLKSEL0 (PCLK_UART1) from the reset value of 00 (use CCLK/4 = 1MHz) to 01 (use CCLK = 1MHz).
>
> I really doubt the problems you are having are a result of the error in the Baud.
> BR= PCLK / [16 DL (1 + DivAddVal/MulVal) ]
> @00000/[16*2(1+1/12)]
> 5385
>
> The error in the Buad: (115385-115200)/115200 <.2%
>
> I would be willing to bet that the device is being overburdened. This is why the receive and transmit functions work at the lower Bauds and not the higher ones.
>
> You can easily verify this by using the PLL to adjust the frequency of the core and thus the Baud of UART1 without modifying any of your existing UART ISR code. See what happens when you increase the frequency to 8MHz (you would have to change DLL=4). The error would still be the same as at 4Mhz but probably would cure the problems you are having.
>
> Once you determine the device is being overburdened, it then becomes a tradeoff of either modifying and optimizing your code for execution time or increasing the CCLK.
>
> If, for whatever reason, you don't want to raise CCLK, an alternative would be to use hardware flow control.
>
> --- In l..., "goodgodgivemeanaliasalready" wrote:
> >
> >
> > Hi all,
> >
> > I am trying to get a simple pass thru of data at 115k from uart 1 to
> > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600 baud
> > rates, everything is fine. I'm running the unit off the 4MHz IRC. I
> > then bumped uart0 up to 115k, had to switch the fractional baud rate
> > settings. No problem, have 9600 baud message coming in UART1, shooting
> > out UART0 at 115k.
> >
> > Then, I tried getting UART1 up to 115k. Should have just been setting
> > the same values for the fractional baud rate and I'd be in good shape,
> > right? Not so much. The data coming in is all garbled as if the
> > fractional change isn't taking.
> >
> > The UART code is running with receive and transmit interrupts enabled.
> > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > background as well. Again, at 9600 baud, the rest of the code is all
> > functioning correctly.
> >
> > For what it is worth, here is the init code for UART1:
> >
> >
> > /***********************************************************************\
> > ******/
> > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > {
> > U1IER = 0x00; // disable all interrupts
> > U1IIR; // clear interrupt ID
> > U1RBR; // clear receive register
> > U1LSR; // clear line status register
> >
> > // set the baudrate
> > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > U1DLL = (UCHAR)baud; // set for baud low
> > byte
> > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> >
> > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > {
> > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > }
> >
> > // set the number of characters and other user specified operating
> > parameters
> > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > U1FCR = fmode;
> >
> > #ifdef UART1_TX_INT_MODE
> > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > uart1_tx_running = 0;
> > #endif
> >
> > #ifdef UART1_RX_INT_MODE
> > // initialize data queues
> > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> >
> > // enable receiver interrupts
> > U1IER |= UIER_ERBFI;
> > #endif
> > }
> >
> > Does anyone have any ideas / suggestions to look at on this? I have
> > electrically scoped the system when it is running at 115k and verified
> > that the same test data is coming into the port electrically at the
> > higher baud rate. I just can't seem to get the LPC to suck in the bits
> > at 115k vs. 9600.
> >
> > Thanks!
>

An Engineer's Guide to the LPC2100 Series

Hello goodgodgivemeanaliasalready

I just recently read your message...

I assume somewhere in your code you have modified bits 9 and 8 of PCLKSEL0 (PCLK_UART1) from the reset value of 00 (use CCLK/4 = 1MHz) to 01 (use CCLK = 1MHz).

I really doubt the problems you are having are a result of the error in the Baud.
BR= PCLK / [16 DL (1 + DivAddVal/MulVal) ]
@00000/[16*2(1+1/12)]
5385

The error in the Buad: (115385-115200)/115200 <.2%

I would be willing to bet that the device is being overburdened. This is why the receive and transmit functions work at the lower Bauds and not the higher ones.

You can easily verify this by using the PLL to adjust the frequency of the core and thus the Baud of UART1 without modifying any of your existing UART ISR code. See what happens when you increase the frequency to 8MHz (you would have to change DLL=4). The error would still be the same as at 4Mhz but probably would cure the problems you are having.

Once you determine the device is being overburdened, it then becomes a tradeoff of either modifying and optimizing your code for execution time or increasing the CCLK.

If, for whatever reason, you don't want to raise CCLK, an alternative would be to use hardware flow control.

--- In l..., "goodgodgivemeanaliasalready" wrote:
> Hi all,
>
> I am trying to get a simple pass thru of data at 115k from uart 1 to
> uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600 baud
> rates, everything is fine. I'm running the unit off the 4MHz IRC. I
> then bumped uart0 up to 115k, had to switch the fractional baud rate
> settings. No problem, have 9600 baud message coming in UART1, shooting
> out UART0 at 115k.
>
> Then, I tried getting UART1 up to 115k. Should have just been setting
> the same values for the fractional baud rate and I'd be in good shape,
> right? Not so much. The data coming in is all garbled as if the
> fractional change isn't taking.
>
> The UART code is running with receive and transmit interrupts enabled.
> I'm running a 1 millisecond timer on timer 0, PWM is active in the
> background as well. Again, at 9600 baud, the rest of the code is all
> functioning correctly.
>
> For what it is worth, here is the init code for UART1:
>
>
> /***********************************************************************\
> ******/
> void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> {
> U1IER = 0x00; // disable all interrupts
> U1IIR; // clear interrupt ID
> U1RBR; // clear receive register
> U1LSR; // clear line status register
>
> // set the baudrate
> U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> U1DLL = (UCHAR)baud; // set for baud low
> byte
> U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
>
> if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> needed here!!! 115k and 57.6k are 8.51% error otherwise
> {
> U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> }
>
> // set the number of characters and other user specified operating
> parameters
> U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> U1FCR = fmode;
>
> #ifdef UART1_TX_INT_MODE
> uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> uart1_tx_running = 0;
> #endif
>
> #ifdef UART1_RX_INT_MODE
> // initialize data queues
> uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
>
> // enable receiver interrupts
> U1IER |= UIER_ERBFI;
> #endif
> }
>
> Does anyone have any ideas / suggestions to look at on this? I have
> electrically scoped the system when it is running at 115k and verified
> that the same test data is coming into the port electrically at the
> higher baud rate. I just can't seem to get the LPC to suck in the bits
> at 115k vs. 9600.
>
> Thanks!
>

Thanks Richard, your points are well taken and I'll probably adopt some
of your recs.

Good news update:

I have a 14.7456 Mhz oscillator on board as well. I enabled it this
morning and accounted for the clock changes appropriately in the baud
setup. The receives at 115k are now working as expected. So it looks
like it was probably some kind of timing issue / ISR slowness in my
code.

Now my only problem is that my Crossworks JTAG unit won't let me debug
(it drops the JTAG connection when I select the external oscillator as
the clock source). But at least the main problem seems to be accounted
for and solved...

Thanks for all your help everyone...

--- In l..., "rtstofer" wrote:
>
> --- In l..., "goodgodgivemeanaliasalready"
spambite3444@ wrote:
>
> > And again, I'm very confused that the transmit works (and it is a
ISR
> > handled function as well!), but not the RX...
> >
> > I'll look at the timing again, but a 4MHz oscillator should be able
to
> > handle all of this. I have a nauseous feeling that I'm missing
> > something simple, but ...
> >
> > Thanks for your help...
> If I understood what you said, your setup works at 57k baud with a 4
MHz osc but not at 115k baud. Have you thought about just kicking the
osc up to 8 MHz as an experiment?
>
> I usually try to get CCLK at the max and ordinarily set PCLKK.
then again, I am not trying to use low power.
>
> I have never worked with the LPC23xx devices but with the LPC21xx
devices you have to go to a lot of effort to get interrupts to nest. For
example, I have no idea how long your interrupts are disabled.
>
> Another experiment would be to send strings shorter than the FIFO
depth.
>
> There's an oddity (in my view) in the way the FIFOs are implemented.
Basically, you wait for an THRE interrupt and then you have to fill the
FIFO. There is no way to determine whether there is an empty space in
the FIFO. So, when you get the THRE interrupt you need to fill as many
of the 16 slots as possible from the transmit queue.
>
> The receive FIFO is even more interesting as you have the opportunity
to get the interrupt for every character or at 4, 8 or 14 chars. Here
again, you KNOW that at least so many chars are available in the FIFO.
The CTI interrupt will occur if there are chars in the FIFO but not
enough to reach the FIFO level for an interrupt.
>
> So, basically, you should be processing the transmit and receive FIFO
interrupts with chunks of chars from the queues. You don't have to count
chars or loop on status bits, you just have to grab/stuff as fast as you
can because you KNOW the depth of the FIFO.
>
> Richard
>

--- In l..., "goodgodgivemeanaliasalready" wrote:

> And again, I'm very confused that the transmit works (and it is a ISR
> handled function as well!), but not the RX...
>
> I'll look at the timing again, but a 4MHz oscillator should be able to
> handle all of this. I have a nauseous feeling that I'm missing
> something simple, but ...
>
> Thanks for your help...
If I understood what you said, your setup works at 57k baud with a 4 MHz osc but not at 115k baud. Have you thought about just kicking the osc up to 8 MHz as an experiment?

I usually try to get CCLK at the max and ordinarily set PCLKK. then again, I am not trying to use low power.

I have never worked with the LPC23xx devices but with the LPC21xx devices you have to go to a lot of effort to get interrupts to nest. For example, I have no idea how long your interrupts are disabled.

Another experiment would be to send strings shorter than the FIFO depth.

There's an oddity (in my view) in the way the FIFOs are implemented. Basically, you wait for an THRE interrupt and then you have to fill the FIFO. There is no way to determine whether there is an empty space in the FIFO. So, when you get the THRE interrupt you need to fill as many of the 16 slots as possible from the transmit queue.

The receive FIFO is even more interesting as you have the opportunity to get the interrupt for every character or at 4, 8 or 14 chars. Here again, you KNOW that at least so many chars are available in the FIFO. The CTI interrupt will occur if there are chars in the FIFO but not enough to reach the FIFO level for an interrupt.

So, basically, you should be processing the transmit and receive FIFO interrupts with chunks of chars from the queues. You don't have to count chars or loop on status bits, you just have to grab/stuff as fast as you can because you KNOW the depth of the FIFO.

Richard

Hi Alex,

Thanks for the input. I think you may be on the right track by
measuring timing. I have now tried the ports at 57600 baud, which uses
the same divisors, and everything worked as expected! I had been
suspecting a baud rate divisor issue or something similar that I was
missing, but 57600 should be like 115200, just half as fast.

The fact that I am getting the exactly correct characters at 57600 in a
correctly triggered ISR, but I do not even get an ISR interrupt at
115kbaud with short 10 byte bursts at it once per second (I highly
reduced the stream content to try to verify even a limited set of
characters coming in).

DLL = 2 for 115k, = 4 for 57600

DLM = 0 for both

DIVADDVAL = 1 for both, MULVAL = 12 for both

All I do in the ISRs is dump the received FIFO characters into the
software buffer for later processing to minimize any delays in the ISR
itself.

As for the FCR and fmode, it is 0x81 (8 byte FIFO, FIFO enabled). I
call the function like this:

//Init Serial Ports
uart0Init(B115200, UART_8N1, UART_FIFO_8); //COM port 0
uart1Init(B115200, UART_8N1, UART_FIFO_8); //COM port 1

Where I've verified the constants all make sense. Again, the only diff
from 9600, 19200, and 57600 that all work is the first constant, the
B115200. Changing this just affects DLL and DLM, which are correct.

And again, I'm very confused that the transmit works (and it is a ISR
handled function as well!), but not the RX...

I'll look at the timing again, but a 4MHz oscillator should be able to
handle all of this. I have a nauseous feeling that I'm missing
something simple, but ...

Thanks for your help...

--- In l..., "alexander_ribero"
wrote:
>
> Hi:
>
> Do you have access to an oscilloscope or logic analyzer?
>
> If yes, then you should put GPIO pins as outputs and measure the exact
times it takes from the receiving the character to the beginning of the
ISR.
>
> You should compare the UART Receive Pin data versus the moment the ISR
starts executing (known by setting the GPIO High at the beginning of the
ISR) and see if there is enough time to process the interrupt, before
another character arrives from the transmitting source.
>
> You can use this also to verify that the ISR is triggering when you
expect (every character or more than one character in the FIFO), as per
the U1FCR configuration
>
> In your code, it is not possible to see what is the value for the
Register U1FCR, as it is passed as parameter to the function (fmode).
Could you post how you are calling the function or what is the value for
this register?
>
> It would be useful if you post the ISR code as well...
> Are you doing any processing in it, or just putting the characters
into a buffer?
>
> Also, are you checking and detecting frame or overflow errors? How are
you handling them?
>
> Another possibility could be to use DMA to transfer the data directly
to memory...
> Regards,
>
> Alex
>
> --- In l..., "goodgodgivemeanaliasalready"
spambite3444@ wrote:
> >
> > More information -
> >
> > I had debug code in on UART0, and was incorrect. It does not read
characters correctly at 115k either. Both ports are outputting at 115k
correctly, and both can input/output at 9600 (so pin selections, modes
seem to be o.k.).
> >
> > Any suggestions where to look to see why the ISR isn't reading right
at 115k?
> >
> >
> >
> > --- In l..., "goodgodgivemeanaliasalready"
wrote:
> > >
> > >
> > > Hi Jan,
> > >
> > > Thanks for the interest. You're right, I didn't show the DLL and
DLM
> > > numbers explicitly. But for 57600, the divisor just becomes 4 and
the
> > > rest stays the same. The lpc2000uart.baudrate.calculator.xls that
is
> > > out on the web helps to show this.
> > >
> > > I may end up trying 57600 to see if there is something magical
about the
> > > fractional baud rate divisor on UART1. I don't think there is, I
was
> > > thinking it had more to do with the fact that the UART1 has modem
> > > control aspects, but those (I believe) are all turned off by
default.
> > > I've debugged the memory locations and it looks like they should
all be
> > > disabled (i.e. I'm not waiting for any RTS / CTS handshaking
stuff).
> > > And again, it works just fine at 9600...
> > >
> > > Thanks again!
> > >
> > >
> > >
> > >
> > > --- In l..., "Jan Vanek" wrote:
> > > >
> > > > Hi goodgod...,
> > > >
> > > > you didn't send the B115200 and B57600 constants, can you send
it?
> > > >
> > > > For the 57600 the setting could be:
> > > >
> > > > divisor: 3
> > > > mulVal: 9
> > > > divAddVal: 4
> > > >
> > > > For the 115200 the setting could be:
> > > >
> > > > divisor: 2
> > > > mulVal: 12
> > > > divAddVal: 1
> > > >
> > > > DLM = divisor >> 8;
> > > > DLL = divisor & 0xFF;
> > > > FDR = (divAddVal << FDR_DIVADDVAL_BIT) | (mulVal <<
FDR_MULVAL_BIT);
> > > >
> > > > This means the B57600 could be 3 and B115200 could be 2. Can you
also
> > > test the 57600 baud-rate? You need to make a mod in your code
> > > > otherwise you are setting the FDR for 115200 only.
> > > >
> > > > With regards,
> > > > Jan
> > > >
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: "goodgodgivemeanaliasalready" spambite3444@
> > > > To: l...
> > > > Sent: Thursday, October 29, 2009 10:08 PM
> > > > Subject: [lpc2000] Re: LPC2368 UART1 vs. UART0 - 115k baud
issue?
> > > >
> > > >
> > > >
> > > > Hi guys, thanks for the interest...
> > > >
> > > > 1) We are well within the limits to generate the 115k baud using
4M
> > > IRC.
> > > > UART 1 has no limitations in this regard compared to UART 0,
which we
> > > > are doing this on. The base requirement for this is that your
> > > > oscillator is 16 times faster than your desired baud rate. 4M is
> > > almost
> > > > 35 times the desired baud rate.
> > > >
> > > > 2) I am not using the PLL to run the internal clock right now.
But I
> > > am
> > > > using the fractional baud rate dividers to generate the correct
baud
> > > > timing. I am using the 8 character FIFO. When the ISR fires, I
dump
> > > > the data from the FIFO into a buffer for later processing. The
> > > incoming
> > > > data comes out in 1 second bursts of only 10 bytes for my
testing, so
> > > > there isn't really anything happening here other than trying to
get
> > > data
> > > > in.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --- In l..., "alexander_ribero" alexribero@
> > > > wrote:
> > > > >
> > > > > Hi:
> > > > >
> > > > > Are you using the PLL to run the internal clock at higher
> > > frequencies
> > > > than 4MHz? Are you using prescaling the UART clock?
> > > > >
> > > > > At 115k, a byte of data is coming every 86us. Are you using
the UART
> > > > FIFO and triggering interrupts other that every byte? This will
give
> > > you
> > > > time to process the data at that high rate.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Alex.
> > > > >
> > > > >
> > > > > --- In l..., "goodgodgivemeanaliasalready"
> > > > spambite3444@ wrote:
> > > > > >
> > > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > I am trying to get a simple pass thru of data at 115k from
uart 1
> > > to
> > > > > > uart 0 on an lpc2368. Both are enabled (powered) and if I
use 9600
> > > > baud
> > > > > > rates, everything is fine. I'm running the unit off the 4MHz
IRC.
> > > I
> > > > > > then bumped uart0 up to 115k, had to switch the fractional
baud
> > > rate
> > > > > > settings. No problem, have 9600 baud message coming in
UART1,
> > > > shooting
> > > > > > out UART0 at 115k.
> > > > > >
> > > > > > Then, I tried getting UART1 up to 115k. Should have just
been
> > > > setting
> > > > > > the same values for the fractional baud rate and I'd be in
good
> > > > shape,
> > > > > > right? Not so much. The data coming in is all garbled as if
the
> > > > > > fractional change isn't taking.
> > > > > >
> > > > > > The UART code is running with receive and transmit
interrupts
> > > > enabled.
> > > > > > I'm running a 1 millisecond timer on timer 0, PWM is active
in the
> > > > > > background as well. Again, at 9600 baud, the rest of the
code is
> > > all
> > > > > > functioning correctly.
> > > > > >
> > > > > > For what it is worth, here is the init code for UART1:
> > > > > >
> > > > > >
> > > > > >
> > > >
> > >
/***********************************************************************\
\
> > > \
> > > > \
> > > > > > ******/
> > > > > > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > > > > > {
> > > > > > U1IER = 0x00; // disable all interrupts
> > > > > > U1IIR; // clear interrupt ID
> > > > > > U1RBR; // clear receive register
> > > > > > U1LSR; // clear line status register
> > > > > >
> > > > > > // set the baudrate
> > > > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > > > > > U1DLL = (UCHAR)baud; // set for baud low
> > > > > > byte
> > > > > > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> > > > > >
> > > > > > if((baud == B115200) || (baud == B57600)) //Fractional baud
rate
> > > > > > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > > > > > {
> > > > > > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > > > > > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > > > > > }
> > > > > >
> > > > > > // set the number of characters and other user specified
operating
> > > > > > parameters
> > > > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > > > U1FCR = fmode;
> > > > > >
> > > > > > #ifdef UART1_TX_INT_MODE
> > > > > > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > > > > > uart1_tx_running = 0;
> > > > > > #endif
> > > > > >
> > > > > > #ifdef UART1_RX_INT_MODE
> > > > > > // initialize data queues
> > > > > > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> > > > > >
> > > > > > // enable receiver interrupts
> > > > > > U1IER |= UIER_ERBFI;
> > > > > > #endif
> > > > > > }
> > > > > >
> > > > > > Does anyone have any ideas / suggestions to look at on this?
I
> > > have
> > > > > > electrically scoped the system when it is running at 115k
and
> > > > verified
> > > > > > that the same test data is coming into the port electrically
at
> > > the
> > > > > > higher baud rate. I just can't seem to get the LPC to suck
in the
> > > > bits
> > > > > > at 115k vs. 9600.
> > > > > >
> > > > > > Thanks!
> > > > > >
> > > > >
> > > >
> > >
>

Hi:

Do you have access to an oscilloscope or logic analyzer?

If yes, then you should put GPIO pins as outputs and measure the exact times it takes from the receiving the character to the beginning of the ISR.

You should compare the UART Receive Pin data versus the moment the ISR starts executing (known by setting the GPIO High at the beginning of the ISR) and see if there is enough time to process the interrupt, before another character arrives from the transmitting source.

You can use this also to verify that the ISR is triggering when you expect (every character or more than one character in the FIFO), as per the U1FCR configuration

In your code, it is not possible to see what is the value for the Register U1FCR, as it is passed as parameter to the function (fmode). Could you post how you are calling the function or what is the value for this register?

It would be useful if you post the ISR code as well...
Are you doing any processing in it, or just putting the characters into a buffer?

Also, are you checking and detecting frame or overflow errors? How are you handling them?

Another possibility could be to use DMA to transfer the data directly to memory...
Regards,

Alex

--- In l..., "goodgodgivemeanaliasalready" wrote:
>
> More information -
>
> I had debug code in on UART0, and was incorrect. It does not read characters correctly at 115k either. Both ports are outputting at 115k correctly, and both can input/output at 9600 (so pin selections, modes seem to be o.k.).
>
> Any suggestions where to look to see why the ISR isn't reading right at 115k?
>
> --- In l..., "goodgodgivemeanaliasalready" wrote:
> >
> >
> > Hi Jan,
> >
> > Thanks for the interest. You're right, I didn't show the DLL and DLM
> > numbers explicitly. But for 57600, the divisor just becomes 4 and the
> > rest stays the same. The lpc2000uart.baudrate.calculator.xls that is
> > out on the web helps to show this.
> >
> > I may end up trying 57600 to see if there is something magical about the
> > fractional baud rate divisor on UART1. I don't think there is, I was
> > thinking it had more to do with the fact that the UART1 has modem
> > control aspects, but those (I believe) are all turned off by default.
> > I've debugged the memory locations and it looks like they should all be
> > disabled (i.e. I'm not waiting for any RTS / CTS handshaking stuff).
> > And again, it works just fine at 9600...
> >
> > Thanks again!
> >
> >
> >
> >
> > --- In l..., "Jan Vanek" wrote:
> > >
> > > Hi goodgod...,
> > >
> > > you didn't send the B115200 and B57600 constants, can you send it?
> > >
> > > For the 57600 the setting could be:
> > >
> > > divisor: 3
> > > mulVal: 9
> > > divAddVal: 4
> > >
> > > For the 115200 the setting could be:
> > >
> > > divisor: 2
> > > mulVal: 12
> > > divAddVal: 1
> > >
> > > DLM = divisor >> 8;
> > > DLL = divisor & 0xFF;
> > > FDR = (divAddVal << FDR_DIVADDVAL_BIT) | (mulVal << FDR_MULVAL_BIT);
> > >
> > > This means the B57600 could be 3 and B115200 could be 2. Can you also
> > test the 57600 baud-rate? You need to make a mod in your code
> > > otherwise you are setting the FDR for 115200 only.
> > >
> > > With regards,
> > > Jan
> > >
> > >
> > >
> > > ----- Original Message -----
> > > From: "goodgodgivemeanaliasalready" spambite3444@
> > > To: l...
> > > Sent: Thursday, October 29, 2009 10:08 PM
> > > Subject: [lpc2000] Re: LPC2368 UART1 vs. UART0 - 115k baud issue?
> > >
> > >
> > >
> > > Hi guys, thanks for the interest...
> > >
> > > 1) We are well within the limits to generate the 115k baud using 4M
> > IRC.
> > > UART 1 has no limitations in this regard compared to UART 0, which we
> > > are doing this on. The base requirement for this is that your
> > > oscillator is 16 times faster than your desired baud rate. 4M is
> > almost
> > > 35 times the desired baud rate.
> > >
> > > 2) I am not using the PLL to run the internal clock right now. But I
> > am
> > > using the fractional baud rate dividers to generate the correct baud
> > > timing. I am using the 8 character FIFO. When the ISR fires, I dump
> > > the data from the FIFO into a buffer for later processing. The
> > incoming
> > > data comes out in 1 second bursts of only 10 bytes for my testing, so
> > > there isn't really anything happening here other than trying to get
> > data
> > > in.
> > >
> > >
> > >
> > >
> > >
> > >
> > > --- In l..., "alexander_ribero" alexribero@
> > > wrote:
> > > >
> > > > Hi:
> > > >
> > > > Are you using the PLL to run the internal clock at higher
> > frequencies
> > > than 4MHz? Are you using prescaling the UART clock?
> > > >
> > > > At 115k, a byte of data is coming every 86us. Are you using the UART
> > > FIFO and triggering interrupts other that every byte? This will give
> > you
> > > time to process the data at that high rate.
> > > >
> > > > Regards,
> > > >
> > > > Alex.
> > > >
> > > >
> > > > --- In l..., "goodgodgivemeanaliasalready"
> > > spambite3444@ wrote:
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I am trying to get a simple pass thru of data at 115k from uart 1
> > to
> > > > > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600
> > > baud
> > > > > rates, everything is fine. I'm running the unit off the 4MHz IRC.
> > I
> > > > > then bumped uart0 up to 115k, had to switch the fractional baud
> > rate
> > > > > settings. No problem, have 9600 baud message coming in UART1,
> > > shooting
> > > > > out UART0 at 115k.
> > > > >
> > > > > Then, I tried getting UART1 up to 115k. Should have just been
> > > setting
> > > > > the same values for the fractional baud rate and I'd be in good
> > > shape,
> > > > > right? Not so much. The data coming in is all garbled as if the
> > > > > fractional change isn't taking.
> > > > >
> > > > > The UART code is running with receive and transmit interrupts
> > > enabled.
> > > > > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > > > > background as well. Again, at 9600 baud, the rest of the code is
> > all
> > > > > functioning correctly.
> > > > >
> > > > > For what it is worth, here is the init code for UART1:
> > > > >
> > > > >
> > > > >
> > >
> > /***********************************************************************\
> > \
> > > \
> > > > > ******/
> > > > > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > > > > {
> > > > > U1IER = 0x00; // disable all interrupts
> > > > > U1IIR; // clear interrupt ID
> > > > > U1RBR; // clear receive register
> > > > > U1LSR; // clear line status register
> > > > >
> > > > > // set the baudrate
> > > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > > > > U1DLL = (UCHAR)baud; // set for baud low
> > > > > byte
> > > > > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> > > > >
> > > > > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > > > > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > > > > {
> > > > > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > > > > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > > > > }
> > > > >
> > > > > // set the number of characters and other user specified operating
> > > > > parameters
> > > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > > U1FCR = fmode;
> > > > >
> > > > > #ifdef UART1_TX_INT_MODE
> > > > > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > > > > uart1_tx_running = 0;
> > > > > #endif
> > > > >
> > > > > #ifdef UART1_RX_INT_MODE
> > > > > // initialize data queues
> > > > > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> > > > >
> > > > > // enable receiver interrupts
> > > > > U1IER |= UIER_ERBFI;
> > > > > #endif
> > > > > }
> > > > >
> > > > > Does anyone have any ideas / suggestions to look at on this? I
> > have
> > > > > electrically scoped the system when it is running at 115k and
> > > verified
> > > > > that the same test data is coming into the port electrically at
> > the
> > > > > higher baud rate. I just can't seem to get the LPC to suck in the
> > > bits
> > > > > at 115k vs. 9600.
> > > > >
> > > > > Thanks!
> > > > >
> > > >
> > >
>

More information -

I had debug code in on UART0, and was incorrect. It does not read characters correctly at 115k either. Both ports are outputting at 115k correctly, and both can input/output at 9600 (so pin selections, modes seem to be o.k.).

Any suggestions where to look to see why the ISR isn't reading right at 115k?

--- In l..., "goodgodgivemeanaliasalready" wrote:
> Hi Jan,
>
> Thanks for the interest. You're right, I didn't show the DLL and DLM
> numbers explicitly. But for 57600, the divisor just becomes 4 and the
> rest stays the same. The lpc2000uart.baudrate.calculator.xls that is
> out on the web helps to show this.
>
> I may end up trying 57600 to see if there is something magical about the
> fractional baud rate divisor on UART1. I don't think there is, I was
> thinking it had more to do with the fact that the UART1 has modem
> control aspects, but those (I believe) are all turned off by default.
> I've debugged the memory locations and it looks like they should all be
> disabled (i.e. I'm not waiting for any RTS / CTS handshaking stuff).
> And again, it works just fine at 9600...
>
> Thanks again!
> --- In l..., "Jan Vanek" wrote:
> >
> > Hi goodgod...,
> >
> > you didn't send the B115200 and B57600 constants, can you send it?
> >
> > For the 57600 the setting could be:
> >
> > divisor: 3
> > mulVal: 9
> > divAddVal: 4
> >
> > For the 115200 the setting could be:
> >
> > divisor: 2
> > mulVal: 12
> > divAddVal: 1
> >
> > DLM = divisor >> 8;
> > DLL = divisor & 0xFF;
> > FDR = (divAddVal << FDR_DIVADDVAL_BIT) | (mulVal << FDR_MULVAL_BIT);
> >
> > This means the B57600 could be 3 and B115200 could be 2. Can you also
> test the 57600 baud-rate? You need to make a mod in your code
> > otherwise you are setting the FDR for 115200 only.
> >
> > With regards,
> > Jan
> >
> >
> >
> > ----- Original Message -----
> > From: "goodgodgivemeanaliasalready" spambite3444@
> > To: l...
> > Sent: Thursday, October 29, 2009 10:08 PM
> > Subject: [lpc2000] Re: LPC2368 UART1 vs. UART0 - 115k baud issue?
> >
> >
> >
> > Hi guys, thanks for the interest...
> >
> > 1) We are well within the limits to generate the 115k baud using 4M
> IRC.
> > UART 1 has no limitations in this regard compared to UART 0, which we
> > are doing this on. The base requirement for this is that your
> > oscillator is 16 times faster than your desired baud rate. 4M is
> almost
> > 35 times the desired baud rate.
> >
> > 2) I am not using the PLL to run the internal clock right now. But I
> am
> > using the fractional baud rate dividers to generate the correct baud
> > timing. I am using the 8 character FIFO. When the ISR fires, I dump
> > the data from the FIFO into a buffer for later processing. The
> incoming
> > data comes out in 1 second bursts of only 10 bytes for my testing, so
> > there isn't really anything happening here other than trying to get
> data
> > in.
> >
> >
> >
> >
> >
> >
> > --- In l..., "alexander_ribero" alexribero@
> > wrote:
> > >
> > > Hi:
> > >
> > > Are you using the PLL to run the internal clock at higher
> frequencies
> > than 4MHz? Are you using prescaling the UART clock?
> > >
> > > At 115k, a byte of data is coming every 86us. Are you using the UART
> > FIFO and triggering interrupts other that every byte? This will give
> you
> > time to process the data at that high rate.
> > >
> > > Regards,
> > >
> > > Alex.
> > >
> > >
> > > --- In l..., "goodgodgivemeanaliasalready"
> > spambite3444@ wrote:
> > > >
> > > >
> > > > Hi all,
> > > >
> > > > I am trying to get a simple pass thru of data at 115k from uart 1
> to
> > > > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600
> > baud
> > > > rates, everything is fine. I'm running the unit off the 4MHz IRC.
> I
> > > > then bumped uart0 up to 115k, had to switch the fractional baud
> rate
> > > > settings. No problem, have 9600 baud message coming in UART1,
> > shooting
> > > > out UART0 at 115k.
> > > >
> > > > Then, I tried getting UART1 up to 115k. Should have just been
> > setting
> > > > the same values for the fractional baud rate and I'd be in good
> > shape,
> > > > right? Not so much. The data coming in is all garbled as if the
> > > > fractional change isn't taking.
> > > >
> > > > The UART code is running with receive and transmit interrupts
> > enabled.
> > > > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > > > background as well. Again, at 9600 baud, the rest of the code is
> all
> > > > functioning correctly.
> > > >
> > > > For what it is worth, here is the init code for UART1:
> > > >
> > > >
> > > >
> >
> /***********************************************************************\
> \
> > \
> > > > ******/
> > > > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > > > {
> > > > U1IER = 0x00; // disable all interrupts
> > > > U1IIR; // clear interrupt ID
> > > > U1RBR; // clear receive register
> > > > U1LSR; // clear line status register
> > > >
> > > > // set the baudrate
> > > > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > > > U1DLL = (UCHAR)baud; // set for baud low
> > > > byte
> > > > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> > > >
> > > > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > > > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > > > {
> > > > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > > > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > > > }
> > > >
> > > > // set the number of characters and other user specified operating
> > > > parameters
> > > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > > U1FCR = fmode;
> > > >
> > > > #ifdef UART1_TX_INT_MODE
> > > > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > > > uart1_tx_running = 0;
> > > > #endif
> > > >
> > > > #ifdef UART1_RX_INT_MODE
> > > > // initialize data queues
> > > > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> > > >
> > > > // enable receiver interrupts
> > > > U1IER |= UIER_ERBFI;
> > > > #endif
> > > > }
> > > >
> > > > Does anyone have any ideas / suggestions to look at on this? I
> have
> > > > electrically scoped the system when it is running at 115k and
> > verified
> > > > that the same test data is coming into the port electrically at
> the
> > > > higher baud rate. I just can't seem to get the LPC to suck in the
> > bits
> > > > at 115k vs. 9600.
> > > >
> > > > Thanks!
> > > >
> > >
>

Hi Jan,

Thanks for the interest. You're right, I didn't show the DLL and DLM
numbers explicitly. But for 57600, the divisor just becomes 4 and the
rest stays the same. The lpc2000uart.baudrate.calculator.xls that is
out on the web helps to show this.

I may end up trying 57600 to see if there is something magical about the
fractional baud rate divisor on UART1. I don't think there is, I was
thinking it had more to do with the fact that the UART1 has modem
control aspects, but those (I believe) are all turned off by default.
I've debugged the memory locations and it looks like they should all be
disabled (i.e. I'm not waiting for any RTS / CTS handshaking stuff).
And again, it works just fine at 9600...

Thanks again!

--- In l..., "Jan Vanek" wrote:
>
> Hi goodgod...,
>
> you didn't send the B115200 and B57600 constants, can you send it?
>
> For the 57600 the setting could be:
>
> divisor: 3
> mulVal: 9
> divAddVal: 4
>
> For the 115200 the setting could be:
>
> divisor: 2
> mulVal: 12
> divAddVal: 1
>
> DLM = divisor >> 8;
> DLL = divisor & 0xFF;
> FDR = (divAddVal << FDR_DIVADDVAL_BIT) | (mulVal << FDR_MULVAL_BIT);
>
> This means the B57600 could be 3 and B115200 could be 2. Can you also
test the 57600 baud-rate? You need to make a mod in your code
> otherwise you are setting the FDR for 115200 only.
>
> With regards,
> Jan
>
> ----- Original Message -----
> From: "goodgodgivemeanaliasalready" spambite3444@...
> To: l...
> Sent: Thursday, October 29, 2009 10:08 PM
> Subject: [lpc2000] Re: LPC2368 UART1 vs. UART0 - 115k baud issue?
>
> Hi guys, thanks for the interest...
>
> 1) We are well within the limits to generate the 115k baud using 4M
IRC.
> UART 1 has no limitations in this regard compared to UART 0, which we
> are doing this on. The base requirement for this is that your
> oscillator is 16 times faster than your desired baud rate. 4M is
almost
> 35 times the desired baud rate.
>
> 2) I am not using the PLL to run the internal clock right now. But I
am
> using the fractional baud rate dividers to generate the correct baud
> timing. I am using the 8 character FIFO. When the ISR fires, I dump
> the data from the FIFO into a buffer for later processing. The
incoming
> data comes out in 1 second bursts of only 10 bytes for my testing, so
> there isn't really anything happening here other than trying to get
data
> in.
> --- In l..., "alexander_ribero" alexribero@
> wrote:
> >
> > Hi:
> >
> > Are you using the PLL to run the internal clock at higher
frequencies
> than 4MHz? Are you using prescaling the UART clock?
> >
> > At 115k, a byte of data is coming every 86us. Are you using the UART
> FIFO and triggering interrupts other that every byte? This will give
you
> time to process the data at that high rate.
> >
> > Regards,
> >
> > Alex.
> >
> >
> > --- In l..., "goodgodgivemeanaliasalready"
> spambite3444@ wrote:
> > >
> > >
> > > Hi all,
> > >
> > > I am trying to get a simple pass thru of data at 115k from uart 1
to
> > > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600
> baud
> > > rates, everything is fine. I'm running the unit off the 4MHz IRC.
I
> > > then bumped uart0 up to 115k, had to switch the fractional baud
rate
> > > settings. No problem, have 9600 baud message coming in UART1,
> shooting
> > > out UART0 at 115k.
> > >
> > > Then, I tried getting UART1 up to 115k. Should have just been
> setting
> > > the same values for the fractional baud rate and I'd be in good
> shape,
> > > right? Not so much. The data coming in is all garbled as if the
> > > fractional change isn't taking.
> > >
> > > The UART code is running with receive and transmit interrupts
> enabled.
> > > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > > background as well. Again, at 9600 baud, the rest of the code is
all
> > > functioning correctly.
> > >
> > > For what it is worth, here is the init code for UART1:
> > >
> > >
> > /***********************************************************************\
\
> \
> > > ******/
> > > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > > {
> > > U1IER = 0x00; // disable all interrupts
> > > U1IIR; // clear interrupt ID
> > > U1RBR; // clear receive register
> > > U1LSR; // clear line status register
> > >
> > > // set the baudrate
> > > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > > U1DLL = (UCHAR)baud; // set for baud low
> > > byte
> > > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> > >
> > > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > > {
> > > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > > }
> > >
> > > // set the number of characters and other user specified operating
> > > parameters
> > > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > > U1FCR = fmode;
> > >
> > > #ifdef UART1_TX_INT_MODE
> > > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > > uart1_tx_running = 0;
> > > #endif
> > >
> > > #ifdef UART1_RX_INT_MODE
> > > // initialize data queues
> > > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> > >
> > > // enable receiver interrupts
> > > U1IER |= UIER_ERBFI;
> > > #endif
> > > }
> > >
> > > Does anyone have any ideas / suggestions to look at on this? I
have
> > > electrically scoped the system when it is running at 115k and
> verified
> > > that the same test data is coming into the port electrically at
the
> > > higher baud rate. I just can't seem to get the LPC to suck in the
> bits
> > > at 115k vs. 9600.
> > >
> > > Thanks!
> > >
>

Hi goodgod...,

you didn't send the B115200 and B57600 constants, can you send it?

For the 57600 the setting could be:

divisor: 3
mulVal: 9
divAddVal: 4

For the 115200 the setting could be:

divisor: 2
mulVal: 12
divAddVal: 1

DLM = divisor >> 8;
DLL = divisor & 0xFF;
FDR = (divAddVal << FDR_DIVADDVAL_BIT) | (mulVal << FDR_MULVAL_BIT);

This means the B57600 could be 3 and B115200 could be 2. Can you also test the 57600 baud-rate? You need to make a mod in your code
otherwise you are setting the FDR for 115200 only.

With regards,
Jan

----- Original Message -----
From: "goodgodgivemeanaliasalready"
To:
Sent: Thursday, October 29, 2009 10:08 PM
Subject: [lpc2000] Re: LPC2368 UART1 vs. UART0 - 115k baud issue?

Hi guys, thanks for the interest...

1) We are well within the limits to generate the 115k baud using 4M IRC.
UART 1 has no limitations in this regard compared to UART 0, which we
are doing this on. The base requirement for this is that your
oscillator is 16 times faster than your desired baud rate. 4M is almost
35 times the desired baud rate.

2) I am not using the PLL to run the internal clock right now. But I am
using the fractional baud rate dividers to generate the correct baud
timing. I am using the 8 character FIFO. When the ISR fires, I dump
the data from the FIFO into a buffer for later processing. The incoming
data comes out in 1 second bursts of only 10 bytes for my testing, so
there isn't really anything happening here other than trying to get data
in.

--- In l..., "alexander_ribero"
wrote:
>
> Hi:
>
> Are you using the PLL to run the internal clock at higher frequencies
than 4MHz? Are you using prescaling the UART clock?
>
> At 115k, a byte of data is coming every 86us. Are you using the UART
FIFO and triggering interrupts other that every byte? This will give you
time to process the data at that high rate.
>
> Regards,
>
> Alex.
> --- In l..., "goodgodgivemeanaliasalready"
spambite3444@ wrote:
> >
> >
> > Hi all,
> >
> > I am trying to get a simple pass thru of data at 115k from uart 1 to
> > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600
baud
> > rates, everything is fine. I'm running the unit off the 4MHz IRC. I
> > then bumped uart0 up to 115k, had to switch the fractional baud rate
> > settings. No problem, have 9600 baud message coming in UART1,
shooting
> > out UART0 at 115k.
> >
> > Then, I tried getting UART1 up to 115k. Should have just been
setting
> > the same values for the fractional baud rate and I'd be in good
shape,
> > right? Not so much. The data coming in is all garbled as if the
> > fractional change isn't taking.
> >
> > The UART code is running with receive and transmit interrupts
enabled.
> > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > background as well. Again, at 9600 baud, the rest of the code is all
> > functioning correctly.
> >
> > For what it is worth, here is the init code for UART1:
> >
> >
> >
/***********************************************************************\
\
> > ******/
> > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > {
> > U1IER = 0x00; // disable all interrupts
> > U1IIR; // clear interrupt ID
> > U1RBR; // clear receive register
> > U1LSR; // clear line status register
> >
> > // set the baudrate
> > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > U1DLL = (UCHAR)baud; // set for baud low
> > byte
> > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> >
> > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > {
> > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > }
> >
> > // set the number of characters and other user specified operating
> > parameters
> > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > U1FCR = fmode;
> >
> > #ifdef UART1_TX_INT_MODE
> > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > uart1_tx_running = 0;
> > #endif
> >
> > #ifdef UART1_RX_INT_MODE
> > // initialize data queues
> > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> >
> > // enable receiver interrupts
> > U1IER |= UIER_ERBFI;
> > #endif
> > }
> >
> > Does anyone have any ideas / suggestions to look at on this? I have
> > electrically scoped the system when it is running at 115k and
verified
> > that the same test data is coming into the port electrically at the
> > higher baud rate. I just can't seem to get the LPC to suck in the
bits
> > at 115k vs. 9600.
> >
> > Thanks!
>

Hi guys, thanks for the interest...

1) We are well within the limits to generate the 115k baud using 4M IRC.
UART 1 has no limitations in this regard compared to UART 0, which we
are doing this on. The base requirement for this is that your
oscillator is 16 times faster than your desired baud rate. 4M is almost
35 times the desired baud rate.

2) I am not using the PLL to run the internal clock right now. But I am
using the fractional baud rate dividers to generate the correct baud
timing. I am using the 8 character FIFO. When the ISR fires, I dump
the data from the FIFO into a buffer for later processing. The incoming
data comes out in 1 second bursts of only 10 bytes for my testing, so
there isn't really anything happening here other than trying to get data
in.

--- In l..., "alexander_ribero"
wrote:
>
> Hi:
>
> Are you using the PLL to run the internal clock at higher frequencies
than 4MHz? Are you using prescaling the UART clock?
>
> At 115k, a byte of data is coming every 86us. Are you using the UART
FIFO and triggering interrupts other that every byte? This will give you
time to process the data at that high rate.
>
> Regards,
>
> Alex.
> --- In l..., "goodgodgivemeanaliasalready"
spambite3444@ wrote:
> >
> >
> > Hi all,
> >
> > I am trying to get a simple pass thru of data at 115k from uart 1 to
> > uart 0 on an lpc2368. Both are enabled (powered) and if I use 9600
baud
> > rates, everything is fine. I'm running the unit off the 4MHz IRC. I
> > then bumped uart0 up to 115k, had to switch the fractional baud rate
> > settings. No problem, have 9600 baud message coming in UART1,
shooting
> > out UART0 at 115k.
> >
> > Then, I tried getting UART1 up to 115k. Should have just been
setting
> > the same values for the fractional baud rate and I'd be in good
shape,
> > right? Not so much. The data coming in is all garbled as if the
> > fractional change isn't taking.
> >
> > The UART code is running with receive and transmit interrupts
enabled.
> > I'm running a 1 millisecond timer on timer 0, PWM is active in the
> > background as well. Again, at 9600 baud, the rest of the code is all
> > functioning correctly.
> >
> > For what it is worth, here is the init code for UART1:
> >
> >
> >
/***********************************************************************\
\
> > ******/
> > void uart1Init(uint16_t baud, UCHAR mode, UCHAR fmode)
> > {
> > U1IER = 0x00; // disable all interrupts
> > U1IIR; // clear interrupt ID
> > U1RBR; // clear receive register
> > U1LSR; // clear line status register
> >
> > // set the baudrate
> > U1LCR = ULCR_DLAB_ENABLE; // select divisor latches
> > U1DLL = (UCHAR)baud; // set for baud low
> > byte
> > U1DLM = (UCHAR)(baud >> 8); // set for baud high byte
> >
> > if((baud == B115200) || (baud == B57600)) //Fractional baud rate
> > needed here!!! 115k and 57.6k are 8.51% error otherwise
> > {
> > U1FDR |= (1 << U1FDR_DIVADDVAL_BIT); //DivAddVal = 1
> > U1FDR |= (12 << U1FDR_MULVAL_BIT); //MulVal = 12
> > }
> >
> > // set the number of characters and other user specified operating
> > parameters
> > U1LCR = (mode & ~ULCR_DLAB_ENABLE);
> > U1FCR = fmode;
> >
> > #ifdef UART1_TX_INT_MODE
> > uart1_tx_extract_idx = uart1_tx_insert_idx = 0;
> > uart1_tx_running = 0;
> > #endif
> >
> > #ifdef UART1_RX_INT_MODE
> > // initialize data queues
> > uart1_rx_extract_idx = uart1_rx_insert_idx = 0;
> >
> > // enable receiver interrupts
> > U1IER |= UIER_ERBFI;
> > #endif
> > }
> >
> > Does anyone have any ideas / suggestions to look at on this? I have
> > electrically scoped the system when it is running at 115k and
verified
> > that the same test data is coming into the port electrically at the
> > higher baud rate. I just can't seem to get the LPC to suck in the
bits
> > at 115k vs. 9600.
> >
> > Thanks!
>