System_printf interfering with UART

Matt Buonadonna

Other Parts Discussed in Thread: TM4C1233H6PM

I had an issue earlier with System_printf that can be found here. It wasn't printing from different source files for some reason. I got pulled off that problem and never was able to fully investigate why. Recently I added System_printf back into my project and it was "magically" working properly again (which we all know means it probably broke something else).

During development the System_printf of messages was working as expected but other interfaces were being affected, namely UART1 to a Bluegiga WT32i bluetooth module. The UART was not receiving full strings from the bt module and would stop at receiving only 16 bytes of the frame. I verified that entire frames to and from the radio was being sent via a serial sniffer. What was received was not garbled (aka Ascii soup) just cut off at 16 bytes. Baud rates, flow control, etc all checked out.

I finally fixed the UART interface problem by turning "off" (simply commenting out the System_printf calls) System_printf. All frames sent to and received from(receiving being the part that was being interfered with) the bt module are now properly formed and terminated.

My question is, why did System_printf interfere with UART1? How can I bring System_printf back into my project and ensure it won't cause any additional problems?

Thank you,

-Matt

over 10 years ago

0 ScottG over 10 years ago

TI__Mastermind 26780 points

Matt,

What device are you running on, and at what speed?

I’m asking because on some processors, running at a low speed, System_printf() calls might take a significant number of available CPU cycles. I’m wondering if this might be happening in your case and impacting your UART driver.

And just to confirm, you’re still using SysMin, right?

Thanks,
Scott

0 Matt Buonadonna over 10 years ago in reply to ScottG

Intellectual 380 points

The processor is a TM4C1233H6PM at 80MHz.

And sorry, but could you be more specific as to what you mean by "using SysMin"?

SysMin is included in my system built app_pem4f.c file (<xdc/runtime/SysMin.h>) but that's it.

Thanks,

Matt

0 ScottG over 10 years ago in reply to Matt Buonadonna

TI__Mastermind 26780 points

OK, thanks, you’re running plenty fast.

By SysMin I’d meant the system proxy that will handle System_print() output. In your previous thread you’d mentioned how you are using SysMin and flushing the output to the console.

I’d asked because if you’d since switched to using “SysStd” instead for print output, that could easily explain UART trouble because in that case the print statements would be sent over to the debugger host, and there could be significant CPU interruption to do this handshaking with the debugger.

My fallback idea is to do as Sasha suggested on that other thread, to look at the SysMin buffer in the ROV tool and see if you can detect any overwrites of the buffer. Have you tried that?

Also, have you checked task and interrupt stacks with the ROV tool? (Described in the section “ROV for System Stacks and Task Stacks” in Bios_User_Guide.pdf in the “docs” directory of your SYS/BIOS installation.) It might be possible that one of those stacks is overflowing once you start using System_printf(), causing some buffer corruption. In that case, you will need to increase stack sizes.

Hope this helps.

Scott

0 Matt Buonadonna over 10 years ago in reply to ScottG

Intellectual 380 points

Scott Gary said:

I’d asked because if you’d since switched to using “SysStd” instead for print output, that could easily explain UART trouble because in that case the print statements would be sent over to the debugger host, and there could be significant CPU interruption to do this handshaking with the debugger.

So I went back to using a UART to output debug messages to the CCS terminal instead of System_printf that posts to the console. I'm using the basic UART_write() to post messages instead of using System_printf() and System_flush().

void vDEBUG(char * cMsg)
{
  uint16_t uiLen = 0;
  uiLen = strlen(cMsg);
  UART_writePolling(sDebug_UART_handle, cMsg, uiLen);
  UART_writePolling(sDebug_UART_handle, "\r\n", strlen("\r\n"));
//    System_printf(cMsg);
//    System_printf("\r\n");
//    System_flush(); /* force SysMin output to console */
}

Scott Gary said:

My fallback idea is to do as Sasha suggested on that other thread, to look at the SysMin buffer in the ROV tool and see if you can detect any overwrites of the buffer. Have you tried that?

I have not had a chance to look at the buffer since I switched back to using a UART instead of System_printf(). I needed to get project work rolling again and since I have a working debug message interface I haven't looked into it further.

Scott Gary said:

Also, have you checked task and interrupt stacks with the ROV tool? (Described in the section “ROV for System Stacks and Task Stacks” in Bios_User_Guide.pdf in the “docs” directory of your SYS/BIOS installation.) It might be possible that one of those stacks is overflowing once you start using System_printf(), causing some buffer corruption. In that case, you will need to increase stack sizes.

I have used the ROV and their stacks are not being over written. If/when they are I've been getting system faults and I simply increased the corresponding stack size to fix it. However this still didn't solve the problem of System_printf corrupting the UART.

Processors

Processors forum

System_printf interfering with UART