[SOLVED] trouble with serial communication using dspic30f2020 & matlab

[maxwell_30]

hi again everyone!
I am trying to interface a matlab gui with dspic30f2020 over serial communication. My matlab code sends a number (here 67) when i press a certain pushbutton. The muc is then supposed to check if the value received is 67 and if it is, then it has to take a certain action (defined in the if loop).

The problem is, my MUC is able to read the received value and to verify if it is 67 i am also sending the received value back to matlab just before the if loop...which also comes out to be 67. But, for some reason, my code is not entering the if loop inspite of the received value being 67..can someone please help me out..

part of my code for dspic30f2020 is:

int RXflag=0;
int input_string[3];

void __attribute__((__interrupt__, __auto_psv__)) _U1TXInterrupt(void){
	//TXflag=1;
	_U1TXIF=0; //clear RX Interrupt Flag

}

void __attribute__((__interrupt__, __auto_psv__)) _U1RXInterrupt(void){    
	RXflag=1;
    _LATE4= ~_LATE4;
	_U1RXIF=0; //clear RX Interrupt Flag
}
 
void putValue(int x) 
{ 
    while(U1STAbits.UTXBF==1) continue;  //Checks if Buffer is Full and w8ts for it to have one
                                                            location empty 
    U1TXREG=x;
    return;                                            //Loops till Transmission is over 
}   

int getValue(void){
	while(RXflag==0) continue;//Loops till RX Flag=1 meaning one character has been recived 
		RXflag=0;    //resets RX flag 
    return(U1RXREG);  
}

void vref_read(void)
{
    unsigned char AN2msb,AN2lsb,AN3msb,AN3lsb;
    
    ADCPC0bits.SWTRG1 = 1; //start conversion of AN1 and AN2 store 200 samples each
    while(ADCPC0bits.PEND1){} //conv pending becomes 0 when conv complete
    
    AN2lsb =  ADCBUF2 &0x00ff;        // lsb of the ADC result
    AN2msb = (ADCBUF2 &0xff00)>>8;    // msb of the ADC result
    AN3lsb =  ADCBUF3 &0x00ff;        // lsb of the ADC result
    AN3msb = (ADCBUF3 &0xff00)>>8;    // msb of the ADC result
    
    putValue(AN2msb);putValue(AN2lsb);putValue(AN3msb);putValue(AN3lsb);
}

int main()
{
  __delay32(3200);
  //Delay();
  init_ports();
  adc_index=0; 
 
  initUart();
  initialiseADC();  
  __delay32(3200);

  _LATE4=0;

[B] 
while(1)                                                  // part where i am having trouble
 {
   input_string[0]=getValue();
   putValue(input_string[0]);
   
   if(input_string[0] == 67)
   {
       _LATE4= ~ _LATE4;
       vref_read();
   }
}
[/B] 
 return(0);
}

matlab code:

    clc;
    s=serial(upper(get(handles.ip_port,'String')));
    set(s,'BaudRate',115200,'InputBufferSize',1,'Timeout',10);
    fopen(s);
    s;
    
    b=67;
    k=0;
    fwrite(s,b,'int8');
    disp('done')
    k=fread(s);
    disp('k');
    disp(k);                                      //I am getting the output till here, after this i get timeout
                                                     error because no values are transmitted from the MUC
    
    if k==67
        AN1lsb=fread(s);
        AN1msb=fread(s);
        AN2lsb=fread(s);
        AN2msb=fread(s);
    end

 

[Aussie Susan]

Can you use the debugger to check the actual value of the 'input_string[0]' variable?
I suspect that there is some non-zero value in the upper byte that is preventing the comparison from returning true. (After all the UART deals with 8-bit values and it might be putting junk into the top byte when passing back the byte into an integer variable.)
Also, unless this is just an intermediate stage in development, you really don't need to use the interrupts - especially the Tx one - and they are really just complicating the code. You can just as easily spin on the URXDA bit as your 'RXflag' variable and then read directly from U1RXREG.
Susan

 

[maxwell_30]

i tried debugging by displaying the value i receive on an array of leds...as a result i realised that when i send 1, it receives 129 (i.e 0b10000001 instead of 0b00000001)...and this is happening for all the other numbers..i.e. for some reason, the msb is always set high :/...so if i check the for loop for input_string[0]==129 when 1 is sent, it works...bt do u have any idea why this is happening?

Also, only in the case of 32,it receives 128 (0b10000000) always..dont know why :/

 

[Aussie Susan]

You do not show us the 'initUart()' function so it is hard to tell how you have set up the UART.
My guess would be that you have not quite got the BAUD rate set correctly. Because the values are send LSB to MSB and the MSB is followed by the 'stop' bit which is always high, if the BAUD rate settings are not exactly right then the accumulated errors from the preceding bits might be enough for you to just sample the very start of the actual 'stop' bit while thinking it is the last data bit.
Check that the oscillator is at the exact frequency you expect and that the BAUD rate calculation is correct. Also work out the error in the actual BAUD rate as it should be within a few percent of the required value (and this is where I suspect you may have the problem).
Susan

 

[KlausST]

Hi,

As Susan said, I also think it is a baudrate mismatch.

On your error description it seems you sending a bit too fast.
UART usually sends:
* Start bit = 0
* 8 databits lsb first
* Stop bit = 1

It seems it receives the startbit and the lsb correct..but then the incoming datastream is too fast and the receiver decodes the Stop bit as 8th databit.

Klaus

 

[maxwell_30]

I changed my crsytal...its working now thank u so much

 

[KlausST]

Hi,

off topic:

This is an example how your given information helpd to find the cause of the error:

...as a result i realised that when i send 1, it receives 129 (i.e 0b10000001 instead of 0b00000001)...

* You descirbe what you did (send "1")
* You described want you expect (receive 0b 0000 0001)
* and what you received instead: (received: 0b 1000 0001)

Now we could focus on the wrong "1" and what may cause this.

For sure there may be countless other errors that may cause this wrong "1", but the baudrate mismatch is very ofthen with UART communication.
***

I hope this example motivates other thread_startes to give that detailed and focussed error descriptions.
** end to be overly didactic ;-) **

Klaus