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.

TMS470 not firing SCI RX interrupt when disconnected from debugger and power cycled

Other Parts Discussed in Thread: TMS470MF06607

I have an application running on the TMS470MF06607 that uses two SCI ports. One is configured for ~105k baud 8n1 and the other is configured for ~10.4k baud 9n2. The main clock is 10MHz and SCI1/SCI2, which are source from VCLK1, are sourced at 5MHz.

Here is the SciInit function for reference:

void SciInit(void)
{
    // --------------------SCI 1:APP-----------------------
    sciREG1->GCR0       = 1U;
    sciREG1->CLRINT     = 0xFFFFFFFFU;
    sciREG1->CLRINTLVL  = 0xFFFFFFFFU;
    sciREG1->GCR1       = (1U << 25U) /* enable transmit */
                        | (1U << 24U) /* enable receive */
                        | (1U << 5U)  /* internal clock */
                        | (2U << 4U)  /* number of stop bits */
                        | (1U << 1U)  /* asynchronous timing mode */
                        | (1U);       /* address-bit mode */
    sciREG1->BRS        = 29U; // baud = 10417
    sciREG1->FORMAT     = 7U; // length
    sciREG1->FUN        = (1U << 2U) | (1U << 1U);
    sciREG1->DOUT       = 0U;
    sciREG1->DIR        = (1U << 2U);
    sciREG1->ODR        = 0U;
    sciREG1->PD         = (1U << 2U) | (1U << 1U);
    sciREG1->PSL        = 1U;
    sciREG1->SETINT     = (1U << 9U); // Rx
    sciREG1->SETINTLVL  = 0U;
    sciREG1->GCR1      |= (1U << 7U);
    // --------------------SCI 2:DEBUG-----------------------
    sciREG2->GCR0       = 1U;
    sciREG2->CLRINT     = 0xFFFFFFFFU;
    sciREG2->CLRINTLVL  = 0xFFFFFFFFU;
    sciREG2->GCR1       = (1U << 25U) /* enable transmit */
                        | (1U << 24U) /* enable receive */
                        | (1U << 5U)  /* internal clock */
                        | (1U << 4U)  /* number of stop bits */
                        | (1U << 1U); /* asynchronous timing mode */
    sciREG2->BRS        = 2U; // baud = ~105000
    sciREG2->FORMAT     = 7U; // length
    sciREG2->FUN        = (1U << 2U) | (1U << 1U);
    sciREG2->DOUT       = 0U;
    sciREG2->DIR        = 0U;
    sciREG2->ODR        = 0U;
    sciREG2->PD         = 0U;
    sciREG2->PSL        = (1U << 2U) | (1U << 1U) | (1U);
    sciREG1->SETINT     = 0U;
    sciREG1->SETINTLVL  = 0U;
    sciREG2->GCR1 |= (1U << 7U);
}

As you can see, SCI1 is the 9bit application port that is configured to interrupt on RX. SCI2 is a debug port I use to output state information and error messages.

The problem I'm having is that when I run my code attached to the debugger it works fine. When I disconnect the debugger, it continues to work. But if I power cycle the device the code all runs but the RX interrupt on SCI1 stops working.

Here are other things I've tried and notes about the situation:

  • I'm using CCS v6.0
  • I'm using an XDS100V2 and physically connecting or disconnecting it does not solve the problem
  • I've tried changing the optimization level from none to highest -- no change
  • I've monitored the POR and RST lines during debug and when it's disconnected and there is no change, though it should not make a difference because I know the code is running
  • When disconnected from debug and power cycled the transmit for both SCI1 and SCI2 work fine, but are not interrupt driven
  • I've monitored VCLK by redirecting it to ECLK and looking at it on a scope, when in debug or power cycled the clock is solid
  • I've checked signal integrity of the RX line on the device PCB and it appears unchanged whether in debug or not
  • If I power cycle then attach the debugger without resetting or reprogramming the device (attach to a running target) then the interrupt will start working
  • I've tried building in debug/release modes and the outcome is the same

Any help would be appreciated -- this is a pretty interesting and frustrating problem.

  • To add to this:

    I have my debug port printing the contents of SCI1's FLR register and what I'm seeing is when it's connected to the debugger the IDLE bit in FLR is clear, but when I disconnect from the debugger and power cycle it is set. When the IDLE bit is set the SCI cannot receive data.

    I don't really understand this though because I've configured the SCI in Address-bit mode.

  • Hello,

    My first question is, are you using your own board or one of our HDK?

    If it is your own board, that you have a JTAG header and you can plug and un-plug your XDS100 pod. Is it correct?

    When the JTAG connector is not plugged, what is the state of nTRST?

    Can you try cycling the board, without the XDS100, and just try pulling up or down nTRST and see the result?

  • That is quite interesting.

    After running your sci init, it will take 11 bit time for the SCI to synchronize. Any incoming data during that time  will not be received correctly and can leave the SCI waiting for IDLE.
    I suggest to always check for the IDLE bit to be set. Can you try that and see.

    When the debugger is attached, are you running your application from reset and without any break point?

  • I have tried waiting for the idle to clear after I release the SCI from reset with:

    while(sciREG1->FLR & 0x04);

    But when I power cycle and start outside the debugger it just hangs in the init and never clears.

    Yes, when debugging I'm running from reset without breakpoints.

  • This is our own custom board.

    Yes, we have a jtag header for the XDS100.

    I should have noted this in the first post: I looked at nTRST. When debugging the line goes high and stays high. When I stop debugging, it stays high. When I power cycle it's low and stays low. When I manually pull the line high and power cycle it does not fix the problem.

  • I don't understand why the SCI is going idle when I'm using Address-bit mode. In the TMS470 sci reference guide:

    http://www.ti.com/lit/ug/spnu196a/spnu196a.pdf

    It says the idle time between frames is irrelevant in this mode:

    Address-bit mode adds an extra bit (the address bit) into every frame.
    Frames containing an address have the address bit set to 1, and frames
    containing data have the address bit set to 0. In this mode, the idle space
    between frames is irrelevant

  • I fixed the problem but I'm still a little sure of the underlying cause.

    Basically I changed the pins from floating to pullup.

    Before:

    sciREG1->PD  = (1U << 2U) | (1U << 1U);
    sciREG1->PSL = 1U;
    After:

    sciREG1->PD  = 0U;
    sciREG1->PSL = (1U << 2U) | (1U << 1U) | (1U);

    Hope this helps someone else.