• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 82 subscribers
  • Views 395 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS320F2812: Unstable PIE from SCI-A source

Mark Evz
Prodigy 20 points
Part Number: TMS320F2812


Hello,

I am experience an unstable SCI-A RX interrupts to PIE.  When using the debugger or power on the board, most of the time my SCI-A RX FIFO interrupt works just fine.  On random occasion (every 10th or so reset or power on), the SCIA RX FIFO interrupt fails to be acknowledge by the PIE.  I see RXINT be set and am able to successfully clear it through SW, but the PIE source for SCIA RX will never call the iSR until I power cycle the board.  Is this a known issue?  What can cause the PIE to latch up like this?  How to recover in SW without a reset?

  • 0
    TI__Guru 62975 points

    Mark,

    You can find most known issues in the Errata document.

    With emulation debug enabled, it's possible for logic states to carry over between runs. This is not expected to happen during normal operation, but emulation debug has a way of altering behavior in very subtle ways.

    Are you explicitly resetting and clearing PIE and SCI states during device initialization? The interrupt flag (or overflow state) may have been set during the prior run and carried over into the new run. This can result in a scenario where it looks like there is a pending interrupt, but the PIE does not respond to it.

    -Tommy

  • 0 in reply to tlee
    Prodigy 20 points

    This issue seems to repeatable on the debugger and also after the image is loaded to flash with cycling of power (power is off > 30 seconds).  I agree there is a register which should be configured or reset, it is not.

    SCI-A module is initialized by

    SCIFFTX and SCIFFRX has FFOVF set to 1 clear, FIFORESET set to 1, FFINTCLR set to 1 and FFIENA set to 1.

    SCICTL1 SWRESET set to 0 to initiate reset, TX/RX ENA set to 1

    High and Low Baud Rate set

    SCICTRL1 SWRESET set to 1

    PIE IER9 enable INT1and INT2.  IER interrupt source 9 enabled.

    Are there any critical registers in SCI-A that must be initialized?

    In PIE, what sources drive PIEIER9 bit SCIARX to be set?  Is it only RXINT from SCI-A or other signals can drive this signal as well?

  • +1 in reply to Mark Evz
    TI__Guru 62975 points
    Mark Evz said:
    This issue seems to repeatable on the debugger and also after the image is loaded to flash with cycling of power (power is off > 30 seconds).

    This helps to eliminate my original thought that it might be a carryover state.

    Mark Evz said:
    In PIE, what sources drive PIEIER9 bit SCIARX to be set?  Is it only RXINT from SCI-A or other signals can drive this signal as well?

    It would only be the resolved SCI TXINT and RXINT interrupt signals that are shown in the block diagram from the SCI guide:

    Mark Evz said:
    Are there any critical registers in SCI-A that must be initialized?

    I suppose it would make the most sense to reference the sci_loopback_interrupts example from the peripheral examples package. Does this example work reliably for you?

  • 0 in reply to tlee
    Prodigy 20 points

    That's what I thought, RXINT is the only source.  If this is true, it does not make sense.  I've setup two GPIO pins.  One for RXINT status in the background and another GPIO every time the SCIA_RX_ISR() is executed.  In the background, I also have a check statement where if I see RXINT == 1 for 5 cycles, force empty SCI FIFO, acknowledge as if in ISR. 

    When the chip boots normal, I never see the RXINT pin get activated and always the SCIA_RX_ISR().

    When the chip boots abnormal, I always see RXINT pin toggling due to my force clear in background and never see entry in SCIA_RX_ISR().  This should have been enough to kick start PIE but does not seem to work here, as if something else is hanging up the interrupt controller. 

    As a step further, I timer interrupt source at 10 ms is operating normal.

  • 0 in reply to Mark Evz
    TI__Guru 62975 points

    Mark,

    That is helpful profiling information. When in the abnormal state, can you also record these register values:

    PIECTRL
    PIEACK
    PIEIFR6
    PIEIER6
    IFR
    IER

    -Tommy