View Full Version : 16450 UART interupt issue
abachler
04-24-2008, 10:31 AM
With only the RDA interupt enabled, After a charcter is transferred into the holding register and the interupt goes active, I read the character from the RBR and the interupt goes inactive, but it then immediately goes active again. This is a 16450, so there is no FIFO , and no new character has been recieved by the UART. Any idea's on what could cause this?
For now, I am going to try just clearing any other causes fro teh additional interrupt, but I would like to know what is actually causing it.
matsp
04-24-2008, 01:20 PM
In my memory, 8250/16X50 has always been a bit "strange" in their interrupt behaviour, so I'm not entirely surprised that it behaves funny.
What is the value in bits 3-1 of INTID (port 0x2FA for Com1), and bit 0 of the register same? [When that second interrupt comes in, that is]
--
Mats
abachler
04-24-2008, 03:36 PM
bit 3 will always be 0 since this is a 16450, there is no FIFO mode on the 16450. as for bits 0-2 Ill have to return that register on the transmit line. This isnt in a computer, its on a breadboard, I just figured since it is a common chip in comps that this woudl be a decent place to ask.
What I did was write a more thorough interupt handler for each specific IID, although technicalyl only the RDA should ever occur, since the other interupts are disabled.
The secondary interupt is still occuring, but it gets handled a lot sooner.
Dave_Sinkula
04-24-2008, 03:56 PM
Have you looked in your 16450's manual? (Which one? I'm looking at this one (http://japan.xilinx.com/support/documentation/ip_documentation/opb_uart16450.pdf).)
abachler
04-25-2008, 12:50 PM
Yeha, I have the datasheet spread out on my desk. What it came down to was putting in code for every possible interupt, even the ones that 'can't' happen because they are disabled. This seemed t fix it, the second interupt is still occuring, but it gets handled and doesnt cause the system to behave erratically, so probably there was some interupt occuring that is unmaskable. It could be some undocumented feature as well. Either way it seems the UART is operating properly now. Thanks for the suggestions guys.
vBulletin® v3.7.0, Copyright ©2000-2009, Jelsoft Enterprises Ltd.