topic Re: Losing code flow with MC9S08QG8. Help needed. in CodeWarrior for MCU

Losing code flow with MC9S08QG8. Help needed.

neocronos — Wed, 12 Nov 2008 00:09:35 GMT

Hi, I've been working on this project with a couple of MC9S08QG8 and some ZigBee devices. Because of data type issues with the communication protocol, I decided to use Technoman64's itoa code.

Code:

void cargarpaq()
{  
  char oriDirTmp[1];
  char desDirTmp[1];
  char msgTipTmp[2];
  char msgRecTmp[2];
 
  ItoaMsg(&oriDirTmp[0], "", device1, 1, 0);
  oriDirSnd = oriDirTmp[0];

  ItoaMsg(&desDirTmp[0], "", coordin, 1, 0);
  desDirSnd = desDirTmp[0];
   
  ItoaMsg(&msgTipTmp[0], "", msgCateg, 2, 0);
  msgTipSnd[0] = msgTipTmp[0];
  msgTipSnd[1] = msgTipTmp[1];
 
  ItoaMsg(&msgRecTmp[0], "", msgTarea, 2, 0);    
  msgRecSnd[0] = msgRecTmp[0];                         
  msgRecSnd[1] = msgRecTmp[1];                         
 
  rellenela(allSnd);             
}

It does the rutine but then it goes lost at the end, it does't return to where it started, instead, it does some assembly code (which I honestly don't know what is about), then goes to a time interruption and finally it jumps back to a wrong point, missing several rutine calls.

Here is a screenshot of the debugger, if it helps.

I'm guessing I'm having ram or flash memory issues but I wouldn't know well how to solve them, so, I could use some ideas

Thanks in advance.

Re: Losing code flow with MC9S08QG8. Help needed.

neocronos — Wed, 12 Nov 2008 05:59:43 GMT

I just found something. I copied the whole function code and pasted it into the last used function and it worked fine, which means that the code is well written and the problem should be ... no idea.

cargarack(); // To here, and it works good
cargarpaq(); // Copied the code from here

Sorry if it seems a little newbie. It seems to me too, still don't know why it happens.

Re: Losing code flow with MC9S08QG8. Help needed.

CompilerGuru — Wed, 12 Nov 2008 08:07:13 GMT

To write a 2 character number, you need 3 characters, don't forget the terminating 0 byte.
Your code seems not to allocate the byte for the terminating 0 byte.
I'm also not sure why you are using ItoaMsg and not Itoa, the ItoaMsg prepends an secondary string in front, but in your code that additional string is always empty, so it does not do more than Itoa.

Also Itoa's main advanced feature seems to be to support to add a decimal point, to print the number
as fixed point number. Does not look like you need/want/use that so a simpler itoa would be sufficient.
In case you need the added decimal point too, it also needs an output character.

Daniel

Re: Losing code flow with MC9S08QG8. Help needed.

bigmac — Wed, 12 Nov 2008 08:35:55 GMT

Hello,

I notice that you have declared some one element arrays. These are not suitable for storage of string data since there is no allowance made for a terminating null character. The size of each buffer needs to be one more than the required length of the string.

For the conversion of a signed integer value, the buffer size should allow for five decimal digits, plus sign and decimal point, plus the null termination - a minimum buffer length of eight bytes.

Regards,
Mac

Re: Losing code flow with MC9S08QG8. Help needed.

neocronos — Wed, 12 Nov 2008 10:58:22 GMT

Thanks for answering.

Yes, my mistake. I thought that just because I was declaring char [2], there were 3 positions ([0], [1] and [2]). That's what happens when one uses two different languages at the same time .

So, problem solved. Thanks!

@ CompilerGuru: Indeed, I first used Itoa but I had some issues which I couldn't solve. I checked at this forum and foud Technoman64's one, tried it and worked well. And you're right, I could use a simplier Itoa, just to convert short numbers (decimals) into strings. Unfortunately, I couldn't find one and I wouldn't be sure of writing a good one. If anyone wants to drop a link, would be pretty welcome.

Re: Losing code flow with MC9S08QG8. Help needed.

Lundin — Thu, 13 Nov 2008 21:01:32 GMT

Here is some code I once wrote. It is MISRA C compliant, so please bear with all the 'U':s and typecasts. I'm not using it in any production code yet, so should you find any bugs, do let me know!

extern BOOL gpfunc_itoa (uint16 value, uint8 buf[], uint16 buf_size, uint16* bytes_written);
/*
DESCRIPTION        Int to ASCII character conversion for 16-bit integers.

PARAMETERS

  [value]          The integer value to convert.

  [buf]            A pointer to an allocated buffer of [buf_size] bytes that
                   will contain the null-terminated string which is the result.

  [buf_size]       The size of [buf] in bytes.
 
  [bytes_written]  A pointer to an allocated uint16 variable which will contain
                   the number of bytes written by the function.

RETURNS            TRUE if the function was successful, otherwise FALSE.
*/

BOOL gpfunc_itoa (uint16 value, uint8 buf[], uint16 buf_size, uint16* bytes_written)
{
  BOOL    result;
  uint16  div;
  uint16  i;
  BOOL    remove_zeroes;

  i = 0U;
  remove_zeroes = TRUE;
  div = 10000U;

  while((div != 0U) && (i < buf_size))
  {
    uint8 ch;

    ch = (uint8)((value / div) + '0');

    if(remove_zeroes && (ch == '0'))
    {
      if(value == 0U)
      {
        buf[i] = ch;
        i++;
        break;
      }
      else
      {
        ;                                        /* skip leading zeroes */
      }
    }
    else
    {
      buf[i] = ch;
      remove_zeroes = FALSE;
      i++;
    }

    value %= div;
    div /= 10U;
  }

  if(i == buf_size)
  {
    result = FALSE;
  }
  else
  {
    buf[i] = '\0';
    result = TRUE;
  }
 
  return result;
}