It seems that if I don t initialize the variable bTmpSms to something the problem occurs.

I also realized that it is not the printf that is the problem. It is the itoa function. It got me to check that even though I didn t think that was the problem, when I commented the itoa function then the whole code worked.

So I ended up doing this:

u8 GSM_Telit_ReadSms(u8 bSmsIndex)
{
  char bTmpSms[4] = "aaa";    // I still need to find out why this is !!!

  itoa(bSmsIndex, bTmpSms, 10); // Converts the smsindex into a string

  printf("index = %s
", bTmpSms); // This printf caused the code to get stuck in the RTC // byte read function!

  GSM_Telit_RequestModem("AT+CMGR=""1", 10, "CMGR", 5, 0);
  return 1;
}

This is the itoa function I got:

char itoa(int value, char* result, int base)
{
  // Check that the base if valid
  if (base < 2 || base > 36) {
      *result =   ;
      return 0;
  }

  char* ptr = result, *ptr1 = result, tmp_char;
  int tmp_value;

  do
  {
    tmp_value = value;
    value /= base;
    *ptr++ = "zyxwvutsr

qponmlkjihgfedcba9876543210123456789abcdefghijklmnopqrstuvwxyz" [35 + (tmp_value - value * base)]; } while (value);

  // Apply negative sign
  if (tmp_value < 0)
      *ptr++ =  - ;
  *ptr-- =   ;
  while(ptr1 < ptr)
  {
    tmp_char = *ptr;
    *ptr--= *ptr1;
    *ptr1++ = tmp_char;
  }
  return 1;
}

char bTmpSms[3] only has space for "99". If your bSmsIndex is 100 or greater, you will be trying to write to memory that doesn t belong to you.

Edit after the update

I don t have a reference to itoa on my local machine, but I found this one ( http://www.cplusplus.com/reference/clibrary/cstdlib/itoa/ ). According to that reference, the destination array MUST BE LONG ENOUGH FOR ANY POSSIBLE VALUE. Check your documentation: your specific itoa might be different.

Or use sprintf, snprintf, or some function described by the Standard.

Some ideas:

If itoa() is not properly NUL-terminating the string, then the call to printf may result in the machine looking for the NUL forever.

pmg has a very good point.

Also, consider what type the first argument to itoa() is. If it s signed and you re passing in an unsigned integer, then you may be getting an unexpected minus sign in bTmpSms. Try using sprintf() instead.

The change in code is moving the rest of your code around in memory. My guess is that some other part of the code, not listed here, is bashing some random location; in the first case that location contains something critical, in the second case it does not.

These are the worst kinds of problems to track down*. Good luck.

*Maybe not the worst - it could be worse if it were a race condition between multiple threads that only manifested itself once a week. Still not my favorite kind of bug.

What s the value of bSmsIndex you re trying to print?

If it s greater than 99 then you re overrunning the bTmpSms array.

If that doesn t help, then use IAR s pretty good debugger - I d drop into the assembly window at the point where printf() is being called and single step until things went into the weeds. That ll probably make clear what the problem is.

Or as a quick-n-dirty troubleshoot, try sizing the array to something large (maybe 8) and see what happens.

What s the value of bSmsIndex?

If more than 99 it will be three digits when converted to a string. When zero terminated, it will be four characters, but you ve allocated only three to bTmpSms so the null may get overwritten and the printf will try to print whatever is after bTmpSms until the next null. That could access anything, really.

Try to disassemble this area with index = 2 vs. index = %s.