UARTFlushTx (false) is stalling the program

Justinas Zdanevicius said:

What I'm getting on the terminal is:

01234567012345670

This is first 17 characters and then program stalls.

If the program which uses uartstudio hasn't installed the required interrupt handler, then the program can stall because it ends up in the default interrupt handler which just spins in a loop.

To install the usartstudio interrupt handler in the startup_ccs.c file you need to:

- Add a prototype for the UARTStdioIntHandler function:

//*****************************************************************************
//
// External declarations for the interrupt handlers used by the application.
//
//*****************************************************************************
extern void UARTStdioIntHandler(void);

- Add UARTStdioIntHandler in the g_pfnVectors array for the UART0 entry:

    UARTStdioIntHandler,                    // UART0 Rx and Tx

The attached 3568.TM4C123_uart_test.zip CCS project has a call to UARTprintf which outputs all the characters.

I forgot to mention, that the UARTprintf(...) and UARTFlushTx(...) are in GPIO pin interrupt handler. If not in the GPIO interrupt handler, everything works fine. Is this because of interrupt priorities???

My GPIO pin interrupt is registered like this:

void Cfg_SW1(void)
	{
	GPIOPinTypeGPIOInput(GPIO_PORTF_BASE, GPIO_PIN_4);												// Init PF4 as input
	GPIOPadConfigSet(GPIO_PORTF_BASE, GPIO_PIN_4, GPIO_STRENGTH_2MA, GPIO_PIN_TYPE_STD_WPU);		// Enable weak pullup resistor for PF4
	GPIOIntDisable(GPIO_PORTF_BASE, GPIO_INT_PIN_4);        										// Disable interrupt for PF4 (in case it was enabled)
	GPIOIntClear(GPIO_PORTF_BASE, GPIO_INT_PIN_4);      											// Clear pending interrupts for PF4
	GPIOIntRegister(GPIO_PORTF_BASE, GPIOPortFIntHandler);
	GPIOIntTypeSet(GPIO_PORTF_BASE, GPIO_PIN_4, GPIO_FALLING_EDGE);             					// Configure PF4 for falling edge trigger
	GPIOIntEnable(GPIO_PORTF_BASE, GPIO_INT_PIN_4);     											// Enable interrupt for PF4
	}

Thank you, Chester, for the quick reply! But everything is fine with startup file and there is UARTStdioIntHandlerwritten in the interrups vector array.

Justinas Zdanevicius said:

I forgot to mention, that the UARTprintf(...) and UARTFlushTx(...) are in GPIO pin interrupt handler. If not in the GPIO interrupt handler, everything works fine. Is this because of interrupt priorities???

When the processor is executing an exception handler, the exception handler is preempted if a higher priority exception occurs. If an exception occurs with the same priority as the exception being handled, the handler is not preempted, irrespective of the exception number. However, the status of the new interrupt changes to pending.

The NVIC Interrupt Priority registers are all shown as having the same value (i.e. priority) at device reset. Therefore, if the GPIO interrupt handler calls UARTFlushTx then with the default priorities the processor will remain in a tight loop in the GPIO interrupt handler and not allow the UART interrupt handler to execute (which is required to flush the UART software buffer).

While calling IntPrioritySet to set the UART interrupt priority to be higher than the GPIO interrupt handler could be used to avoid this problem, it will still mean the processor will be spinning in the GPIO interrupt handler in the call to UARTFlushTx function until the UART buffer has been flushed and thus prevent the processor from executing any non-interrupt code.

Out of interest, what is the design reason for calling UARTFlushTx inside the GPIO interrupt handler?

[I consider the normal approach is to make the interrupt handler do the minimum to service the interrupt source, with any operation which may "block" deferred to the main code. E.g. if using SYS/BIOS the interrupt handler gives a semaphore which a task is waiting on]

Hello Chester

If the intent is to invoke UART print from the interrupt handler of the GPIO, wouldn't it be better to use the non-buffered version so that the the entire transmission is completed before any further information is processed within and outside the Interrupt handler of the GPIO.

Regards

Amit