Printf issue, MC56f82748

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Printf issue, MC56f82748

931 Views
spacedog
Contributor I

Hi,

 

I'm using the TWR-56F8200 board with the MC56f82748 chip and code warrior 10.6 Build Id 140329.

 

The following code behaves oddly, all optimization is off and it's a basic barebones project from the wizard.

 

#include <stdio.h>

 

int main(void)

{

  int temp = 2;

  printf("%i\n", temp);

  printf(" %i\n", temp);

  while (1) { }

}

 

The output I get is:

 

%i

2


It seems that the first call to printf reads the format variables (i.e. it just prints the string, I tried a few but that's the simplest example).

 

Interestingly it doesn't happen if I add a 'char c[] = "";'. Looking at the debug it appears to happen when the string is stored at location 0 -- debugging into the printf it seems to fail the 'strchr(format_ptr, '%'))' test in the code.

 

Is there a way I can avoid this apart from adding the blank string (which will get removed in the optimization when I turn it on), or a dummy printf earlier.

Labels (1)
Tags (2)
0 Kudos
1 Reply

677 Views
johnlwinters
NXP Employee
NXP Employee

Many programs, especially C programs, check pointers to see if they are "nul".  That means zero.  And that means you can't use it; or does it?

If your data RAM starts at zero, you will encounter bugs sooner or later since a valid pointer to zero may be misconstrued as an invalid or nul pointer.

Unfortunately, the utility functions such as printf are also prone to this hazard.

This is easily gaurded against at the epense of one location of data RAM if you cannot find or work-a-round the bug. Simply alter the link control file such that you tell the system that RAM starts at location 1, not location zero.

To change the .lcf file, if using Processor Expert, use the GUI interface of the CPU component properties (aka bean properties) to adjust the starting address and size (down one) of the RAM available to the linker.

0 Kudos