Has anyone seen the following behavior on the NET+40’s serial port A? I’m seeing what I believe to be an anomaly when reading “Serial Channel Status Register A” on my NET+40(-4). During my ISR, SCSRA occasionally reads back 0x150d which constitutes the following serial line receiver interrupt conditions: ROVER, RHALF, RFULL. These are Rx overrun, Rx FIFO half full, Rx FIFO full. Note that the RRDY (Rx data ready) bit is NOT set, I would expect this bit to be set when there is data in the FIFO. I have also seen the RHALF bit get “stuck” (still asserted after FIFO drain) and the ROVER bit not clear after writing (this is a write to clear bit). Since these behaviors require workarounds in my ISR, any feedback that might help me to make them go away would be appreciated. - Tom
There is an Errata which relates to this, although the Errata mentions the TX FIFO, and not the RX FIFO: 1.1 SER Module THALF Indicator Failure when writing BYTES/HWORDS Please refer to Section 7.5.3 Serial Channel Status Register A The THALF bit does not work properly when writing BYTES or HALF WORDS to the FIFO data register. The behavior is erratic when writing BYTES or HALF WORDS to the FIFO. This can cause a unannounced FIFO overrun condition when polling the THALF bit to determine when more data can be written to the FIFO. This problem does not occur when writing LONG WORDS to the FIFO data register. The FIFO contains 8 rows of 4 byte entries. Anytime a Long Word, Half Word, or Byte is written to the FIFO, one entire row is consumed. The FIFO considers itself half full when 16 bytes have been written to the FIFO, not when 4 rows have been written. Hence, writing 4 bytes to the FIFO results in four rows being consumed, with only 4 bytes sitting in the FIFO. The FIFO half condition is only triggered when 16 bytes are in the FIFO, which fails in this condition. Work Around Never use the THALF status bit when filling the FIFO using BYTE or HALF WORD writes. Only use the TEMPTY status bit when writing BYTE or HALF WORDS. Correction This erratum is a result of a design limitation in the current chip; the problem is under investigation. The RX FIFO is suffering from the same issue.
Thanks for the reply! I was able to find the errata you mention in the NET+50 document. Does this also apply to the NET+40-4? There isn’t mention of this problem in the NET+40 specific errata. If this also affects RX, what is the recommended workaround? Thanks again, Tom
If you allow me get into this discursion I would like to put that I also got the same problem using NET+50’s serial port B: - reading 0x150d from serial status register in a read operation; - RHALF bit get “stuck”; - RRDY (Rx data ready) bit is not set in that conditions and I cannot read data I think should be available since the FIFO is halffull/full/over. Have you already got the answer for the question: If this also affects RX, what is the recommended workaround ?
I have not gotten any feedback on the recommended workaround. Currently, I reset the UART when I determine that the RHALF bit gets stuck as it seems the only way to get out of that state. I have also seen the RHALF without RRDY, again, a reset seems the only solution. The only problem with reset is that you sometimes “split” a character and get a framing error. Regards, - Tom
Tom,thank you for the help. I will try the reset. best regards, Rogerio