Post Go back to editing

MAX14830 Rx Overrun

Category: Software
Product Number: MAX14830

Hello support,

I'm using a MAX14830 quad UART under FreeRTOS with my own driver.

So far I have failed to run a test sequence that would raise the Rx overrun flag.

The test sequence basically sends 136 bytes into the Rx of one UART with the software not reading the RHR. After 128 bytes the Rx FIFO is expected to be full. 128 bytes are successfully read, and then the FIFO is viewed as empty as expected. However, the extra 8 bytes that were sent did not set the Rx overrun status.

I've tried polling the Line Status Register, as well as triggering an interrupt on Rx errors, but failed to get this Rx overrun status set or generate an interrupt.

Other tests are successful in getting the other error conditions: parity, framing, break. The interrupt on error occurs for all error conditions but the Overrun.

Any hint about how to get this guy set when an overrun occurs?

Thank you.

Parents
  • Hi Hardy,

    Please excuse my late response on this. I would be happy to help you debug this.

    I have tried replicating the test you described, but I could see that the RxOverrun bit in the LSR register set when I send 136 bytes into an empty RxFIFO. That being said, if I read the LSR register before reading the RHR - the RxOverrun bit is set andthe LSRErrInt bit in the ISR register is set. If, however, I read the RHR before reading the LSR or ISR registers, RxOverrun is cleared and the LSRInt bit is set - indicating that there was an LSR issue since the last ISR read.

    You mentioned that you have tried polling the LSR - can you explain that in a little more detail? When are you polling the register?  What are your IRQEn and LSRIntEn register settings before you send data to the RHR? Likewise, what are the ISR and LSR reading before and after you send data to the RHR and read the data?

    Thanks,

    Shasta

  • Hi Shasta,

    Thank you so much for coming back on this concern. Your confirmation that the RxOverrun bit actually works takes a weight off me. As my memory is unreliable I need to put back some instrumentation code before I can provide the details. More to come.

    Thanks,

    Hardy-

  • Hi Shasta,

    Problem solved. An impolite RTOS task I wasn't aware of was messing with the registers, occasionally stealing the line status.

    Thank you for your support.

    Hardy-

  • Hi Hardy,

    Thank you for getting back to me, and I am happy to hear that the issue has been resolved!  Please feel free to contact us again if you have any further questions.

    Best,

    Shasta

Reply Children
No Data