Problems with arguments receiving in functions.

[Saga]

Hi to all, im using codewarrior for an embedded system an i was doing some write/read memory routines, everything was working fine but suddenly the compiler turns strange with the parameters receiving, here is an actual code ill explain what happens after it:

This is the calling to the function on the code:

writeByteToEeprom ('@', 0x1600, 0); //just write anything for testing purposes.

This is the actual function:

short writeByteToEeprom (unsigned char value, int address, short page)
{
unsigned char *Pointer = NULL;
short couldWrite = 1;

if (address >= 0x1600 && address = 0x17FF) //Validating the address
{
//MCGInit(); //Configure the unit's clock to 40 mhz and the bus to 20 mhz.
if (page > 1 || page 0)
page = 0;
FCNFG_EPGSEL = page;
FOPT_EPGMOD = 1; //8 byte sector
FCDIV_PRDIV8 = 1; // divide the bus frequency / 8.
FCDIV_DIV = 12; //Set fFCLK to 192.3 khz (necessary for the flash and EEPROM programming).
while (FCDIV_DIVLD == 0)
; //Ensure that the divisor has loaded correctly.
FSTAT_FACCERR = 0; //Ensure that this flag is cleared.
Pointer = (unsigned char *)address;
*Pointer = value;
FCMD = 0x20; //Byte program command code.
FSTAT_FCBEF = 1; //Launch the command
while ((FSTAT & FSTAT_FCCF_MASK) == 0) //Wait until the write is done, and stop if an error occurs.
{
if (FSTAT_FACCERR == 1)
{
couldWrite = 0;
break;
}
__RESET_WATCHDOG();
}
}
else
couldWrite = -1;

return couldWrite;
}

When debuggin (or running) the program, the function receives the argument variables as listed:

value = 1 (instead of 64, the @).
address = 124 (instead of 5632 (0x1600)).
page = 16384 (instead of 0).

I attach a screenshot of the debugging window. Im using a dbm.

The strange thing is when it calls the function it receives the parameters ok but when the pointer of the line goes into the brackets {} the parameters values change to the values above. This is the first time im working on an embedded system so if you have som advises they are welcome. Also i attach an image where you can see the change from the correct values (when the debugger pointer is at the very first line of the function) and the strange values (when the debugger pointer change to the next line of the function).

Thank you in advance!

Message Edited by Saga on 2006-11-0701:53 PM

[CrasyCat]

Hello

Are you sure you have a prototype for function writeByteToEeprom  in your source file before actually invoking the function?

To check that generate the preprocessor listing for your source file and check whether the prototype is present.

To generate the preprocessor listing:

  - Select the source file in the .mcp window

  - Click on the file name with the right mouse button

  - Select "Preprocess". There will be a new edit window opened containing pre-processor listing.

The symptoms you are explaining are typical when you call a function and do not have a prototype available for the function.

I hope this helps.

CrasyCat

[ehestigoni]

Hey mate,

I'm having the same problem that Saga had. However, It happens in a function of the SMAC protocol...
When I call the function from main () in my c file called "range_demo_plus_TX.c" :

if (MCPSDataRequest(&sTxPacket) == SUCCESS)


sTxPacket is a struct , and the values of all its arrays are ok.

But then, when I step into the function (which is in another file called "symple_phy.c") the pointer loose the value and shows "yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy" instead of the right value as before...

This is the function:


UINT8 MCPSDataRequest (tTxPacket *psTxPacket)
{
    UINT8 u8Status;
   
    /* Send it to the phy for processing */
    u8Status = PDDataRequest(psTxPacket);
    return u8Status;
}

I already checked what you said about the declaration. It is made in another file that is included, called "APP_SMAC_API.h"

extern UINT8 MCPSDataRequest(tTxPacket *psTxPacket);

I've made some tests modifying the parameter. And when I declare and use the function without a pointer as parameter, like:

UINT8 MCPSDataRequest (tTxPacket psTxPacket)

The value is kept just fine. But then, as you can see there is another call inside MCPSDataRequest that uses the same pointer to the referred structure... And guess what? The same problem happens again. When I step into PDDDataRequest, the pointer gets crazy and shows "yyyyyyyyyyyyyyyyyyyyyyyyy" again...

 It seems that if I use a pointer as parameter to the function, it doesn't work...


Any idea of what could be causing this??


Thanks mate.

Cheers,

Ed.

[CompilerGuru]

When I understand the issue correctly,  then your issue is completely different from the one of the OP.
I guess in your case, the debugger does not show the right values, but the code will actually do the correct thing non the less.
For your MCPSDataRequest function (with the pointer argument), the compiler does not need to do anything than to just forward the call to PDDataRequest.
MCPSDataRequest:
>  0000 cc0000   [3]             JMP   PDDataRequest

So the actual issue is with the debug information for psTxPacket, that this argument is never stored on the stack and the compiler is not emitting debug information for values hold in register only :smileysad:.

Daniel

[ehestigoni]

Hi Daniel,

Thanks for your help mate.

However, the value seems to be really wrong...

The struct sTxPacket has five bytes in an array (0x05, 0x00, 0x01, 0x00, 0x02, 0xA0) and the value 6 in another int var. When I pass the pointer to the functions, they are suppose to send this array of only 6 bytes to the transceiver via SPI.

But as the pointer is is lost, what is being sent is 65 bytes off 0x00 and 0xFF...

I will do more tests on monday, and will let you know what happens next.

Cheers mate,

Ed.

[CecchiSandrone]

Hey ehestigoni, did you solve your problem? I'm having the same  but I can't find a solution for it!

[ehestigoni]

Hey Mate,

Actually I did not find a solution... And as the SMAC protocol was to slow for my app I decided to program my own firmware getting rid of all function calls inside other function calls. (that saved a lot of processing time...)

Whith no "encapsulation" of code (function inside function) things are more clear, and the problem just disapeared...


Not sure if I can help you much...

Cheers,

Ed.

[CecchiSandrone]

I will do the same

[Saga]

Hi crasycat, its receiving the parameters correctly now! Thank you a lot. I'm having another trouble now... Don't now if it is correct to make a new post to asking it but ill ask here... Here's the thing: I have two functions to write to the non volatile memories (EEPROM and FLASH), i have:

short writeByteToFlash (char, short);
short writeByteToEeprom (char, short, short);

When im debugging and im running them step by step both functions work fine... but when i just run the program it doesn't write to the flash, instead of that it works strange and a message tells me on the command window "Preset breakpoint encountered".
And also: ILLEGAL_BP

Im wondering why is that? The writeByteToEeprom function works perfectly fine, im feeding the dog in every cycle i have on the function. Probable im making a novice mistake?

I have good C/C++ Experience programming but this is my very first applications for this kind of systems!

Here is the function:

short writeByteToFlash (char value, short address)
{
char *Pointer = NULL;
short couldWrite = 1;

if (address >= 0x7C00 && address = 0xFFFF) //Validating the address
{
FCDIV_PRDIV8 = 1; // divide the bus frequency / 8.
FCDIV_DIV = 12; //Set fFCLK to 192.3 khz (necessary for the flash and EEPROM programming).
while (FCDIV_DIVLD == 0)
__RESET_WATCHDOG(); //Ensure that the divisor has loaded correctly.
FSTAT_FACCERR = 0; //Ensure that this flag is cleared.
Pointer = ( char *)address;
*Pointer = value;
FCMD = 0x20; //Byte program command code.
FSTAT_FCBEF = 1; //Launch the command
while ((FSTAT & FSTAT_FCCF_MASK) == 0) //Wait until the write is done, and stop if an error occurs.
{
if (FSTAT_FACCERR == 1)
{
couldWrite = 0;
break;
}
__RESET_WATCHDOG();
}
}
else
couldWrite = -1;

return couldWrite;
}

Thanks for your help guys its very appreciated.

Message Edited by Saga on 2006-11-0810:53 AM

Message Edited by Saga on 2006-11-0810:55 AM

[J2MEJediMaster]

I don't think you want the COP active at all while programing EEPROM or Flash. See this thread here, which covers a similar situation, that of the Flash programming working fine in the debugger, but not stand-alone on the board.

---Tom

[Saga]

Ok I've read that the COP is the watchdog right? Well i had understood that you must be reseting it all the time... am i right? How do i disable it? Thank you man

[Saga]

Hey are you sure im able to disable the COP because other functions need it and this is the description of the bits that control the state of the COP Watchdog (in the datasheet).

COP Watchdog Clock Select — This write-once bit selects the clock source of the COP watchdog. See Table 5-6 for details.
0 Internal 1-kHz clock is source to COP.
1 Bus clock is source to COP.

[J2MEJediMaster]

What datasheet are you referring to? You're correct in that the setting the COP clock would be a write-once operation. However, you can disable the COP from triggering an interrupt or a reset. You'd want to do this during EEPROM or Flash memory programming because those operations take so long. Then you'd re-enable the COP once the memory programming is done. Use the datasheet to check the purpose of the bits in the system configuration registers. There should be a bit that determines what the COP does.

---Tom