Lpc2000

I have a small problem with the wait states of the tl16c754. I have
made a test method for writing and reading to some addresses. To the
address of lcr i can write and read. But to the address of mcr I can't
write or read to it. Both have the possebility to read and write. When
The cs and bls signals are working when I write 0xaa and 0x55 to the
quad uart.I look at the address lines and data lines by scope I see
that the lines are triggered.
I think that it has to do with the wait states. Now the BCFG register
is set to 0x0000ef8f. With a maximum WST1 and WST2 wait state and IDCY
to it's maximum. I have tried to set the AURT and just write a
character to it but that doesn't work. Has anyone a solution for this
problem.
I have tried to changing some wait states but still i have this issue.
Can somebody help me with this issue.

remco

You never have to change anything you got up in the middle of the
night
to write.
-- Saul Bellow

I have a small problem with the wait states of the tl16c754. I have
made a test method for writing and reading to some addresses. To the
address of lcr i can write and read. But to the address of mcr I can't
write or read to it. Both have the possebility to read and write. When
The cs and bls signals are working when I write 0xaa and 0x55 to the
quad uart.I look at the address lines and data lines by scope I see
that the lines are triggered.
I think that it has to do with the wait states. Now the BCFG register
is set to 0x0000ef8f. With a maximum WST1 and WST2 wait state and IDCY
to it's maximum. I have tried to set the AURT and just write a
character to it but that doesn't work. Has anyone a solution for this
problem.
I have tried to changing some wait states but still i have this issue.
Can somebody help me with this issue.

remco

You never have to change anything you got up in the middle of the
night
to write.
-- Saul Bellow

> I have a small problem with the wait states of the
> tl16c754. 

I strongly suspect you DO NOT!  We used this same TI
chip, and after weeks of sweat and tears messing with
wait states etc. we found that the problem relates to
the TI chip bus not working in the manner the data
sheet claims.

I implemented a work around, that has been working 
reliably for months now.

Before each read or write operation, I write a dummy
value to the scratch pad register.

This solved the problem.

FYI: I use only 2 wait states to the UART, but can't
remember that I checked if this is required or not.

> I have
> made a test method for writing and reading to some
> addresses. To the
> address of lcr i can write and read. But to the
> address of mcr I can't
> write or read to it. Both have the possebility to
> read and write. When
> The cs and bls signals are working when I write 0xaa
> and 0x55 to the
> quad uart.I look at the address lines and data lines
> by scope I see
> that the lines are triggered.
> I think that it has to do with the wait states. Now
> the BCFG register
> is set to 0x0000ef8f. With a maximum WST1 and WST2
> wait state and IDCY
> to it's maximum. I have tried to set the AURT and
> just write a
> character to it but that doesn't work. Has anyone a
> solution for this
> problem.
> I have tried to changing some wait states but still
> i have this issue.
> Can somebody help me with this issue.
> 
> remco
> 
> You never have to change anything you got up in the
> middle of the
> night
> to write.
> -- Saul Bellow
> 
> 
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

--- In lpc2000@yahoogroups.com, "catstransport" <remco@u...> wrote:
> I have a small problem with the wait states of the tl16c754. I have
> made a test method for writing and reading to some addresses. To the
> address of lcr i can write and read. But to the address of mcr I can't
> write or read to it. Both have the possebility to read and write. When
> The cs and bls signals are working when I write 0xaa and 0x55 to the
> quad uart.I look at the address lines and data lines by scope I see
> that the lines are triggered.
> I think that it has to do with the wait states. Now the BCFG register
> is set to 0x0000ef8f. With a maximum WST1 and WST2 wait state and IDCY
> to it's maximum. I have tried to set the AURT and just write a
> character to it but that doesn't work. Has anyone a solution for this
> problem.
> I have tried to changing some wait states but still i have this issue.
> Can somebody help me with this issue.

Wait States is not the problem. We are using the same chip and after
stuffing around for a couple of weeks we finally found that the device
is in some legacy mode. The address lines are ignored and one need to
access it in a 2 step process. First write the address to device.
(i.e. Address of register in data byte) The next access then reads or
writes the data from the register pointed to by the first access. 
Please contact TI regarding this matter. When we contacted them we got
a very unsatisfactory reply. Hopefully if more people complain about
this, they would fix the device or provide a way to switch so that it
works as specified in the datasheet.

Regards
  Anton Erasmus

After two interesting posts. The problem is solved.

I have made two method a read and a write. For each register change in
the uart I call this method with the register address. Before I write
the address I write something (0xff) to spr register. After that I
read or write the register with the correct value.

this seems to work for writing to the register I still have a problem
with my ISR ad the moment but it will be solved in a day.

regards,

remco

--- In lpc2000@yahoogroups.com, "catstransport" <remco@u...> wrote:
> After two interesting posts. The problem is solved.
> 
> I have made two method a read and a write. For each register change in
> the uart I call this method with the register address. Before I write
> the address I write something (0xff) to spr register. After that I
> read or write the register with the correct value.
> 
> this seems to work for writing to the register I still have a problem
> with my ISR ad the moment but it will be solved in a day.

After my changes I can write to the uart and read from it. But only
50% of my data comes over the UART. So every second character is
thrown away from the buffer or it is just somewhere but nog thrown
away to the comport.

I know that the that the methods are reading and writing from the
buffer. When I do a large sleep in my putString method so that the
PutChar will be less called from the string each second. Then he
doesn't mess with the data. But this is to slow for me. I have made
ISR method the same as the LPC2292 ISR UART method. Does someone know
the different between these two.

best regards,

Remco

You're working under a slight handicap.  You happen to be human.

On 22 Jul 2005 at 7:55, catstransport wrote:

> --- In lpc2000@yahoogroups.com, "catstransport" <remco@u...> wrote: >
> After two interesting posts. The problem is solved. > > I have made
> two method a read and a write. For each register change in > the uart
> I call this method with the register address. Before I write > the
> address I write something (0xff) to spr register. After that I > read
> or write the register with the correct value. > > this seems to work
> for writing to the register I still have a problem > with my ISR ad
> the moment but it will be solved in a day.
> 
> After my changes I can write to the uart and read from it. But only
> 50% of my data comes over the UART. So every second character is
> thrown away from the buffer or it is just somewhere but nog thrown
> away to the comport.
> 
> I know that the that the methods are reading and writing from the
> buffer. When I do a large sleep in my putString method so that the
> PutChar will be less called from the string each second. Then he
> doesn't mess with the data. But this is to slow for me. I have made
> ISR method the same as the LPC2292 ISR UART method. Does someone know
> the different between these two.
> 
Because of the nature of our comms, we could poll the quad uart from a timer interrupt
routine. (once every 1ms). Even at 115200 baud, it takes over 5 ms to send 64 bytes, 
so polling is aviable alternative. The device has got some extended features, such as 
the large FIFO's from the "Standard" PC Uart. Unfortunately, while all the "PC 
Compatible" UARTs are the same for their basic operation, the extra features are not 
standardised at all.

Regards
  Anton Erasmus
-- 
A J Erasmus