Called function 'loses' the value of a passed variable

[Couch]

Hi guys,

I'm working on troubleshooting a problem where it appears that a called function 'loses' its value once the

function is called. Im using PCM 3.185, and a PIC 16F877. The code snippets below highlight the areas of the

problem.


code from main.c to call the function.

OurID = '0';
errcode=send_message('A',OurID, 'F', 5,"ABCDE");


Code from 485.c


#use rs232(baud=9600, xmit=RS485_TX_PIN, rcv=RS485_RX_PIN, enable=RS485_ENABLE_PIN, force_sw, multi_master,

stream=RS485_CD)
.
.
.

int send_message( int to, int cmd, int len, int * data ) {
// Format: source | destination | data-length | data | checksum

int try,i,cs;

disable_interrupts(global);
RCV_OFF();

fputc(to,RS485_CD); // Recipient ID
fputc(rs485_id,RS485_CD); // Senders ID
fputc(cmd,RS485_CD); // Command byte
fputc(len,RS485_CD); // Data Length.
blah blah blah
.
.
.

To simplify my troubleshooting I only have one pic on the bus, and a PC 'evesdropping' to monitor the Serial

transmission. The code above will work fine with the code above, and the first few bytes seen in PC Hyperterminal:

A0F.....
^
------ A is Recipient ID
^---- 0 is senders ID
^--- F is the command


The code works fine and when multiple pics use the same routine, I have tested the bus with accurate data and no

errors with close to a million packet transmissions.
The problem came recently where I wanted to add another byte to the packet being sent. What happens is as soon as

I add code to send the additional byte, the Recipient ID (the 'to' variable) is sent as a null. This is confirmed

in PC terminal, and also that all slaves 'ignore' the packet since it is addressed to no one. The following

snippet is the added code (hardcoded right now to debug the problem):

fputc(to,RS485_CD); // Recipient ID
fputc(rs485_id,RS485_CD); // Senders ID

// THE ADDITION OF THE EXTRA BYTE CAUSES THE 'TO'
fputc('A',RS485_CD); // THIS LINE ADDED FOR DEBUGGING PURPOSES
fputc(cmd,RS485_CD); // Command byte
fputc(len,RS485_CD); // Data Length
I have the problem isolated to where the 'to' variable is passed in the function. The value of 'A' should be passed to the function in the variable 'to', but for some reason it is null once the function is executed. I confirmed this by adding the following line as the first line in the "send_message" function:

to='A';
The first byte, along with the rest, are now transmitted correctly. I was going to 'workaround' the problem by simply using global variables, but I'd like to close the issue by understanding what has caused the problem.

Note I also have simplified the test by removing the 485 transceivers (to eliminate the possibility of an ENABLE bit timing issue), and the problem persists.

I suspect the extra code is possibly causing the code to overlap page banks? Any suggestions would be welcome...


Thanks
Dave

[Neutone]

Try using a string that is the packet of data you want to send. You can change the individual bytes in the string then send the whole string. Try some preformated strings.

[PCM programmer]

[Couch]

PCM and Neutone,

Thanks very much for the responses (your support to this forum is admirable to say the least, I have learned a ton from you guys!). I have to apologize for my first post - the errors that PCM noted are due to me using an old example from work, and manually making the changes to show the error, while the real code is at home! Being in the support business, I should know better than that (and post the identical problem, not just an interpretation)!

PCM, the two errors you pointed out are actually typos I made in my post - in my code I do have the following :

errcode=send_message('A', 'F', 5,SendData);

-- OurID is not sent to the function, it is global.
-- A defined Int array is sent, not a constant string

As mentioned, the data transmission works great until I add the extra putC command. At that point the first byte is sent as a null. Neutone, tonight I will certainly try populating a buffer as you suggest. Still confused why the above example is giving me problems.

thanks again for your help
Dave