Printf delaying SRIO interrupts on C6474 EVM target.

gareth james

I am using CCS 3.3.82.13, with DSP/BIOS 5.33.04, an XDS510USB emulator, and C6474 EVM target board.

I am using printf() in my main task to periodically output status information to CCS (via the emulator-jtag-USB path).

But I am finding that at times the printf() function appears to cause delays or death of SRIO message transactions.

Note that I am not using printf() from within any interrupt code, or software interrupt thread, it is only being used in the background main task, and is being used with a low frequency, so is not flooding the output with printf() data.

Aditionally a colleague has seen similar effects when developing code to support I2C devices via interrupt, but again is only using printf() from NON interrupt code.

It would suggest that the printf() function (along with the CCS-emulator path) is somehow causing some sort of resource or peripheral contention, which in turn either stalls the SRIO hardware interrupts, or DMA transfers, or possibly is disabling various interrupts in some manner.

The questions are:

1] Has anyone else encountered this behaviour?

2] Is it a bug in the DSP/BIOS and printf() functionality?

3] Is it some sort of semaphore action that is blocking other hardware interrupts, or service routines?

4] Is there a work round, apart from not using printf()?

over 16 years ago

0 TimHarron over 16 years ago

TI__Mastermind 18130 points

gareth james said:
1] Has anyone else encountered this behaviour?

Because printf() follows the C standard it is cumbersome and slow. This sort of behavior is typical because the system has to stop and wait for the printf() call to complete.

gareth james said:
2] Is it a bug in the DSP/BIOS and printf() functionality?

3] Is it some sort of semaphore action that is blocking other hardware interrupts, or service routines?

No, this is not a bug. The printf() call must run to completion without interruption and as a result interrupts may be missed.

gareth james said:
4] Is there a work round, apart from not using printf()?

I suggest using the LOG module (LOG_printf(), specifically) to work around this. LOG_printf() is non-invasive to the rest of your code. It is a quick function call and is able to minimize the latency by storing the messages on the host inside the COFF file. You can find a pretty good description of this function at the Embedded Processors wiki. Note that there can be a sometimes lengthy delay when using LOG_printf(), especially with high system loads.

To swap from printf() to LOG_printf() you will need to add an object inside the LOG module of your DSP/BIOS configuration (Instrumentation->LOG - Event Log Manager->(Right click)->Insert LOG). You can give it any name you like, but because some of our example material names this object 'trace' I will use that name. Once the LOG object is created you can customize the properties if you like, but the defaults should work for most situations.

Next you will need to add the both the log header file (log.h) and the DSP/BIOS-generated configuration header file (biosfilenamecfg.h) into any source files that will use the LOG_printf(). At this point you can replace

printf("message\n");

with

LOG_printf(&trace, "message\n");

This should help alleviate the pain of using the big and slow printf() calls.

*edit* I've gone ahead and created a Wiki article discussing this process here.

0 gareth james over 16 years ago in reply to TimHarron

Prodigy 90 points

Thanks Tim and Brad.

I think that clearly answers my questions.

I will now switch to the LOG_printf() method.

I had used LOG_printf() in some other test code, so should not have too much trouble switching.

Processors

Processors forum

Printf delaying SRIO interrupts on C6474 EVM target.