• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 171 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.

TM4C1294NCPDT: TM4C1294NCPDT

Byron Blue
Prodigy 110 points
Part Number: TM4C1294NCPDT


I'm working on the operating system for a commercial sonar.
This testing phase is using a TM4C1294XL LaunchPad as a platform.
I'm using the UART3_BASE for the serial port at 4800 baud to receive instructions from the host operating system.
The port interrupt is set to receive interrupt and the receive timeout interrupt:
UARTIntEnable( UART3_BASE, UART_INT_RX | UART_INT_RT);
During the command receive phase the system captures ~40 bytes of command information then jumps into a receive phase. During the receive cycle the system will receive packets of 5 bytes of stabilization information. Both sentences use 0x9F as a termination character.
I was having issues with the system losing synchronization at a few ranges.
Through some bits of analysis I found the command section was jumping out of the gathering loop prior to receiving the complete message. My thought was the serial port was holding the end of a stabilization message when it entered the command.
I disabled the FIFO then found by disabling the UART_INT_RX when entering the stablization phase then enabling it as I left the routine the system ran great.
This seems fine but I want to know why this works. The documentation is a little sparse. And what size is the FIFO by default?
Thank you everyone for any information,
Byron

  • 0
    TI__Guru**** 191886 points

    Hi Byron,

    Byron Blue said:
    Through some bits of analysis I found the command section was jumping out of the gathering loop prior to receiving the complete message. My thought was the serial port was holding the end of a stabilization message when it entered the command.

    I don't really know what happens but glad that you found a solution. However, I can't explain why it works perhaps I still yet to understand your exact setup.  Are you processing the command inside the ISR for UARTRX? Is it possible that you spend too much time in ISR to process commands while receive cycle has started by OS or you are spending too much time in ISR for the receive cycle while command cycle has started by OS? In either case, UARTRX may overflow. You can check if you are getting an overrun flag in UARTDR register or UARTRSR register. When you disable FIFO, you get an interrupt for each char that is received. I think it may have helped to alleviate your synchronization issue. 

    Byron Blue said:
    And what size is the FIFO by default?

    The FIFO is 16x8 deep. The RX interrupt can be configured to generate based on a certain percentage the FIFO is full. By default, when half of RXFIFO is full, an interrupt is generated. You can change the FIFO level to generate interrupts. See below API. 

  • 0 in reply to Charles Tsai
    Prodigy 110 points

    Thank you Charles

    Here is my interrupt handler with some bits of code I used for troubleshooting:

    void
    HOST_MSG_ISR( void)
    {
    static int i, j;
    uint32_t ui32Status;
    int32_t tempChar;
    static bool stabMessage = false;


    /* Grab the status of the interrupt... */
    ui32Status = UARTIntStatus( UART3_BASE, true);

    /* Clear the asserted interrupt... */
    UARTIntClear( UART3_BASE, ui32Status);
    stabMessage = false;

    /* Only operate on a receive interrupt... */
    if ( ui32Status & ( UART_INT_RX | UART_INT_RT))
    {
    Pulse_Message_LED();

    while( UARTCharsAvail( UART3_BASE))
    {
    tempChar = UARTCharGetNonBlocking( UART3_BASE);
    /* Check if the character is 0x95... */
    if (( tempChar == REC_STAB_HDR) && ( duringReceive))
    {
    msg_ready = false;
    stab_ready = false;
    stabMessage = true;
    msg_not_stabilized = false;
    j = 0;
    }

    if ( !duringReceive)
    {
    stabMessage = false;
    }

    if ( !stabMessage)
    {
    stab_ready = false;
    msg_not_stabilized = true;

    receiveBuffer[ i++] = tempChar;

    if ( tempChar == REC_BREAK_HDR) /* 0x96... */
    breakReceive = true;

    if ( receiveBuffer[ i - 1] == TERM_CHR)
    /* If we've reached the 0x9F... */
    {
    i = 0; /* Restart the position in the buffer... */

    msg_ready = true; /* Set the msg_ready flag... */
    }
    else
    msg_ready = false;
    }
    else
    {
    stab_buf[ j++] = tempChar;

    if ( stab_buf[ j - 1] == TERM_CHR) /* If we've reached the 0x9F... */
    {
    stab_ready = true;
    stabMessage = false;
    /* Copy the pitch and roll to temporary storage... */
    pitchValue = stab_buf[ 1];
    rollValue = stab_buf[ 2];
    j = 0; /* Restart the position in the buffer... */
    }
    }
    }
    return;
    }
    }

    Now that I've seen the FIFO was likely set to 8 bytes I believe I understand the issue. Stabilization is always sending 5 bytes: 0x95 (start of stabilized), pitch (char), roll (char), 0x00 and 0x9F (termination). If three bytes were in the FIFO exiting the routine the two left over would be 0x00, 0x9F. This would cause the command portion to fall through immediately putting the system in an endless cycle. This is why killing the RX interrupt at that time works.

    Thank you so much for your time and efforts here,

    Byron