Is there a limit to the number of LOG_printf() calls in a project?

Hi Chuck Peplinski.

The LOG_printf() function is a legacy API that's meant for BIOS 5.x support when building with SYS/BIOS 6.x.  Are you porting a legacy BIOS 5.x app to build/run with SYS/BIOS 6.x?

Can you attach your app's configuration (*.cfg) file?

I'm wondering how the LOG object you have configured to use in your LOG_printf() calls is configured.  Maybe it is a fixed buffer (instead of circular) and you're running into issues when the buffer fills up.

You may want to try configuring your app to use SysMin combined with System_printf() and System_flush() calls.

Another thing is you are using a pretty old version of SYS/BIOS.  Have you tried using the later version that was installed with your CCS 5.3?  It's possible that you're hitting a problem that's been fixed in a later version of SYS/BIOS.

Steve

OK, I'll attach an obscured version of my .cfg file.

I've inherited a large batch of legacy code and so far my client hasn't exhibited any desire to update components.  When I've accidentally tried the newer versions, the project didn't build.  Maybe you can give me some reasons why that might be a good idea?  Or suggest a migration guide?

I use LOG_printf() to get a relatively large and verbose trace without impacting real time very much.  I probably have "too many" calls now.  The limit I describe is not how many times the function is called.  It is how many instances are in the code.  I reduced my crash to the state where adding one more LOG_printf() call to a piece of code that is not executed would result in crashes when calling LOG_printf somewhere else.  I interpret this to mean that I have overflowed the table of strings that is built up on the host to "unpack" the 4 word buffers written into the log.  Using a 32k entry buffer, as I am, results in quite slow operation, but it works.

If there is a better way to get a high performance printf type trace log, I'm open to the suggestion.  It has to be printed to a buffer that is retrieved off line.  I need more tracing than printf can keep up with.  My brief look at system_printf() did not yet reveal this feature, but that's why I ask you.

I'll "insert" the file here.  I hope that's the same as attach.  I don't see an attach button.

4456.x.cfg

Hi Chuck,

Chuck Peplinski said:

I've inherited a large batch of legacy code and so far my client hasn't exhibited any desire to update components.  When I've accidentally tried the newer versions, the project didn't build.  Maybe you can give me some reasons why that might be a good idea?  Or suggest a migration guide?

I took a look at your *.cfg file ... it's quite a mix of legacy settings combined with BIOS 6.x settings.  There is a migration guide available - I'll point you to it for reference, but for now I'd say you should probably hold off on traveling down that road as the migration can be tricky and time consuming.  I'm not sure you need to go there yet.

The legacy porting guide can be found under your SYS/BIOS installation, for example it's here on my machine:

    C:\ti\CCS5.3.0.00090\bios_6_34_02_18\docs\Bios_Legacy_App_Note.pdf

Chuck Peplinski said:

I use LOG_printf() to get a relatively large and verbose trace without impacting real time very much.  I probably have "too many" calls now.  The limit I describe is not how many times the function is called.  It is how many instances are in the code.  I reduced my crash to the state where adding one more LOG_printf() call to a piece of code that is not executed would result in crashes when calling LOG_printf somewhere else.  I interpret this to mean that I have overflowed the table of strings that is built up on the host to "unpack" the 4 word buffers written into the log.  Using a 32k entry buffer, as I am, results in quite slow operation, but it works.

I see that your trace LOG buffer is configured to be circular in your *.cfg file.  So, once it has been entirely filled with LOG data, the next call to LOG_printf will just be written to the beginning of the LOG buffer (wrapping around).  I don't think the buffer would have overflowed.

Chuck Peplinski said:

 I reduced my crash to the state where adding one more LOG_printf() call to a piece of code that is not executed would result in crashes when calling LOG_printf somewhere else.

I think this may be an important clue.  Can you clarify on this?  You added a LOG_printf call to code that's *not* executed, and that caused your app to crash?

If so, I suspect there may be another reason.  It's possible that there is some code somewhere in your application that's overwriting memory it shouldn't be.  For example, a buffer overflow could be happening, in which some code is overwriting some memory that it should not have access to.

What we've seen in the past is that the offending code has been stomping on the memory all along, but sometimes there is no associated crash because the memory it's overwriting doesn't actually contain any valid code or data.

But, when additional code is added or changes are made, it causes the memory map to change, and valid code or data is then placed at the exact spot in memory that the buffer overflow is trashing.

Then, it appears that a small addition that should in no way cause a crash did just that.  But, the new addition only revealed an underlying problem that was there all along.

I'm now mostly convinced that these problems are due to memory overwrites of some sort.  I've removed at least one.  But I've still got some questions.  

What does error -8 from xdc.rta.Formatter mean?  In certain configurations, I get this error in the Eclipse window when I try to view the LOG_printf window, but it is empty.

Other times I get this "handler conflict".  What does this mean?  Or are these questions for the CCS forum?

The answers to these questions will help me find the problems in my code.