Hi All My on going hell with the NET+50 UARTs continues… The 4 byte wide window on the RX FIFO is causing me no end of problems… I really need to get notification of a single character being received but the delay between characters I’m receiving is very short… With the gap timer on and the timeout set to 11 bit periods or less (@9600 baud) I don’t appear to get a buffer closed condition… My understanding was the buffer gap timer is started when the first character is fully received and closes the buffer when the timeout expires… I was expecting that if I set the timeout to less than a character period I would get a buffer closed for the first character when receiving two back to back characters… When I acknowledge the first RXBC and read the character I’d get the buffer closed for the second one… Experiment have shown that I never get the buffer closed condition for either character and if enough back-to-back character are received eventually I get an overrun condition that appears to totally lockup the UART… Anyone know how the buffer gap timer really works? Also anyone know how I can get the UART to tell me it has received a single character even when the time between them is short (i.e. ~1 bit period)? Regards, Dave PS setting the gap to 33 bit periods works (causes buffer closed conditions) with well interspersed character… so I know the buffer gap timer works…
The TXBC field in the Serial Channel Status Register A, unfortunately is not working. TXBC is not functional on the 40 - for UART/SPI/HDLC modes. Also it is not functional for serial UART mode on the 50 as well. However, the work-a-round is to use TXEMPTY and TXHALF (fifo half full). This is because Net+Arm does not set TXBC (Transmit Buffer Closed Interrupt Pending). At this point, you can get interrupt before XMT buffer is closed. You need to wait until FIFO is empty. The Net+Arm 40 chips sets TXEMPTY (Transmit FIFO Empty) bit correctly, so you wait for 5 bytes max where as for Net+Arm 50 you must wait for 9 bytes max since 1 byte is added for the shift buffer
I know the TXBC flag is broken… and I’m having to use one of the two counter timers triggered on the TXEMPTY flag to tell me when the character has left the FIFO and shift register… My latest question is about the RXBC flag… Is there a way to get notification of a single character being received when character are being sent on the line to the NET+50 as fast as they can by a PC? Using the Buffer closed gap timer only appears to close the buffer (set RXBC) when characters are well interspersed? In fact it appears to work more like a character gap timer… Regards, Dave
Hi Dave. I also have an ongoing hell but with the NS7520. I also needed to get a notification of a single character but i tried using the character gap timer. I had similar problems like you with a buffer closed interrupt for cases where the buffer shouldn’t be closed (I don’t understand how they have implemented the UART but it doesn’t work very well). My solution though, is to use the match interrupt. I use this by masking all bytes i.e. no matter what character is received there is a match, this causes the buffer closed interrupt to be asserted and the singe byte can be read. The downside with this is that the ISR will run everytime one character is received, but it works anyway. In order to detect gaps in a packet I use a thread that look at an event flag that is asserted each time a byte has been received, if that flag hasn’t been received for a while there is a gap and a new packet is expected. This is not a good solution but since the UART isn’t working what do you do. P.S Try to avoid sending breaks from the PC. My protocol uses break signals and it sometimes crashes the entire system. Don’t know why yet but i am getting very tired of this UART.
Hi Jesper > My solution though, is to use the match interrupt. I > use this by masking all bytes i.e. no matter what > character is received there is a match, this causes > the buffer closed interrupt to be asserted and the > singe byte can be read. The downside with this is > that the ISR will run everytime one character is > received, but it works anyway. Sounds like this is what I’ll have to do as well… fortunately at 9600 baud this is only going to happen about 5 times per 5 ms task tick… so shouldn’t be too much of a problem… I hope… > P.S Try to avoid sending breaks from the PC. My > protocol uses break signals and it sometimes crashes > the entire system. Don’t know why yet but i am > getting very tired of this UART. Unfortunately in my protocol too I get breaks… two in fact, followed by an unspecified number of back-to-back ESC chars, and then finally the useful message… 
Thanks, Dave
The problems I am having with the break signal is that currently I am generating the break signal from the PC (this is just for test). This break signal was initially 100ms long. In order to get that to work I has to disable the interrupt when i got a break interrupt. When the break signal was completely sent I then enabled the interrupt again (I have a thread that checks if the rxd pin goes high ones a break has arrived to check that…ugly solution but I am out of ideas). Don’t ask me why it doesn’t help to just ack the interrupt but is doesn’t (not for me anyway). I don’t know if the system gets trapped in the ISR because if I set a breakpoint in the ISR everything works since then the break signal is long gone once i stop in the ISR. I can also put a breakpoint before sending the packet and then it works, which I find strange (the break signal is sent after the packet as a response to the packet). When i executed the system without disable the interrupt and 100ms break signal i could send perhaps 5-6 packets and then the system crashed (no thread executes). When I made the break signal shorter (5ms) I could send 18000 packets before the system crashed ;-((. I don’t know if this is a solution (i am currently running an over night test to see if it crashes) and i still don’t know what causes it. If you get strange behavior when using the break signal and you figure out what it is, or if you have any ideas about how my problem can occur please tell me.
Will do… Regards, Dave