• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 467 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.

TMS320C5517: transmiter holding register empty interrupts no longer being received after a certain elapsed time from app start ?!

citizen
Expert 2840 points
Part Number: TMS320C5517

Tool/software:

Hi,

I would like to know of possible causes for the transmitter holding register empty interrupts no longer being received after a certain time from starting the app ?!

Essentially, I have configured the UART on the C5517, the isrAddr.tbeiAddr to point to my interrupt service routine in which I post a semaphore when I require to know the state of the UART transmit register FIFO - that is to know when it is empty. The reason for this is to test if the UART Tx FIFO is empty so that I may proceed and execute some specific code just after this event ...

The testing thus far shows these interrupts occurring as expected once the main() is started, however I'm noticing that not too far in the code, about 20 seconds in or so, for whatever reason, these interrupts are no longer received.

This makes me wonder why this is the case and how to resolve it ? It would be useful to know for what reasons this might occur, and if there is some other means to observe when & why these interrupts stop being posted ?

For instance are there other conditions that need to be satisfied, other than the FIFO going empty, and if these conditions for some reason are not being met any longer due to some other register settings being overwritten or some flags not being cleared etc, as it might possibly happen ?

Essentially how may I view/test for conditions that correctly post this interrupt, compared to when it is no longer posted (for whatever reason), so that I may prevent the halting of these interrupts during program execution ? For the intended code to execute correctly the FIFO empty interrupt needs to be serviced consistently.

Any thoughts or suggestions how to go about this or why it might occur after some elapsed time ?

Cheers, MM

  • 0
    TI__Guru 55265 points

    Hi There,

    It is most likely the ETBEI bit (Bit 1) of the IER(0x1B02) Interrupt Enable Register has been disabled. If that is the case, please set a breakpoint in UART_eventDisable() at the case CSL_UART_XMITOR_REG_EMPTY_INTERRUPT. See where and when it gets called to be disabled.

    Best regards,

    Ming

  • 0 in reply to Ming Wei
    Expert 2840 points

    G'day Ming,

    Thanks for your quick reply. I am using a precompiled CSL_3.08.01 library to build my project. So setting a breakpoint directly at that line 826 in the csl_uart.c file is not practical. Are you suggesting that I should instead build my existing project with the original source code for the CSL ? 

    Otherwise FYI I can confirm I did consider looking to see what the ETBEI setting is, just before the SEM_pend() where I verify the XMITOR_REG_EMPTY_INTERRUPT semaphore being dispatched :

    CSL_Status BT_fputs(CSL_UartHandle hUart, const char * pBuf)
{
	const char * buf = pBuf;
	CSL_Status status = CSL_SOK;

	hUart->uartRegs->LCR=0x0003;                                            // set DLAB=0 and WLS=8 bit.
	LOG_printf(&trace, "hUart->uartRegs->IER = %d", hUart->uartRegs->IER);  // print IER
	LOG_printf(&trace, "buf = %s", buf);                                    // print BT command.

	SET_MUX_DSP_BT()												// Set UART MUX to point to the BT.
	wait(25);														// 1us delay.
	status += UART_fputs(hUart, buf, 0);		                    // Send BT command.

	if(SEM_pendBinary(&sem_uart_tx_done, 100))						// FOR DEBUG Wait at most 500ms for the UART Tx buffer to be empty.
	{
		(module.BluetoothBaud == 115) ? wait(1400) : wait(12800);	// Small delay to finish Tx of last 2 UART bits (delay depends on BAUDRATE).
        return(status);
    }
    else
        exit(EXIT_FAILURE);                                         // UART comms error.
    
    return(status);
}

    I set a breakpoint at exit() and the LOG_printf is hUart->uartRegs->IER = 3 as the reading before the breakpoint when everything was running normally.

    So unless the ETBEI bit is being reset and then set again before the semaphore timing out, I can't say for certain that it looks like ETBEI is set back to 0, when originally it is configured to be set to 1.

    Only other thing I can think about is if there are more UART_fputs("STATUS\r") happening all of a sudden, than the UART can actually transmit (full transmission of the STATUS\r will take at most 608us), however this seems unlikely given the system-tick is in the milli-seconds and some of the context switches will likely be way over a 1ms. This should allow the UART TX FIFO buffer to empty, which is definitely the case when the app boots up and starts, then for some reason later the ETBEI interrupts stop occuring, and the semaphore times out to an exit(1) which I consider a UART exception.

    Any thoughts on this ?

  • +1 in reply to citizen
    Expert 2840 points

    Just a quick update. I added UART_eventEnable(hUart, CSL_UART_XMITOR_REG_EMPTY_INTERRUPT); on entry of the above function and now the ETBEI interrupts continue as intended, so they were being switched off somewhere. I need to look into it further... but if this resolves the issue permanently then for the moment it's fine unless it happens again. Thanks for the suggestions !