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.

System_printf() causes error within UART callback function

Other Parts Discussed in Thread: CC2650

Hello, working with the CC2650 LaunchPad for CCS6 with the "UART_ECHO" example. I made small modifications to use callbacks instead of blocking for the UART driver. Within my UART write callback I tried both "System_printf()" and "System_flush()" and every variation between the two. Both cause the program to crash and go into "Error_policySpin" loop. This is the callback:

void writecb(UART_Handle handle, void *buffer, size_t num)
{
	System_printf("WRITECB");
}

Here is the driver config code:

UART_Params_init(&uartParams);
uartParams.writeMode = UART_MODE_CALLBACK;
uartParams.readMode = UART_MODE_CALLBACK;
uartParams.writeDataMode = UART_DATA_TEXT;
uartParams.readDataMode = UART_DATA_TEXT;
uartParams.writeCallback = &writecb;
uartParams.readCallback = &readcb;
uartParams.readEcho = UART_ECHO_ON;
uartParams.baudRate = 115200;

uart = UART_open(Board_UART0, &uartParams);
if (uart == NULL) {
	System_abort("Error creating UART!");
}

I then simply call UART_Write() once and I have a breakpoint within the callback to verify it is being entered (which it is). If the program doesn't get an error and go into the error loop, the print does nothing. System_flush() usually guarantees an error. Any help is appreciated.

  • Hi DMor,

    In the case of the CC2650 UART driver, the callback function is called in the context of a Swi. By default, the System_printf() and System_flush() API's are not able to be called from either Hwi's or Swi's as they can block program execution. Please see the answers to the following threads for more information:

    e2e.ti.com/.../153100

    e2e.ti.com/.../400477

    Best,
    Alexander
  • I believe at some point I attempted changing from SysMin to SysStd and posting a SWI from the callback which then proceeded to execute the print command (both which failed). This explains why posting the SWI failed, i'm still not sure why SysStd failed.

    Reading these solutions, you are saying the best work around is to avoid System_printf() and instead use Log_write1() and view the log history after execution? Out of curiosity, if I wanted to print something from a HWI or SWI, what would be the best method? Something along the lines of a dedicated task which executes System_printf() with a semaphore posted?
  • Hi DMor,

    The simplest solution would be to use Log_print statements within your Hwi and view the log history. This is because it's much less intrusive than using Sytem_printf and should have minimal impact on your program execution. As a side note you may enable instrumentation on our drivers as well in your .cfg file by uncommenting this line:

    //driversConfig.libType = driversConfig.LibType_Instrumented;

    Best,
    Alexander