I am trying to communicate my PC(master) with microcontroller PIC18f45k22(slave) using uart protocol(rs232). Slsve accepts query from PC and also response correctly the first time, but when PC sends query the second time a framing error occurs. i am really stuck up here. somebody please help me out?

 

It might be that transmission starts before the receiver is ready to catch it. That, and the obvious problems of baud rate. Are you using any hardware handshaking such as RTS/CTS?

 

Framing errors have to do with the timing of the stop bit. The archaic protocol was 1.5 or 2 STOP bits where the line had to remain idle (MARKing) during that period. In modern implementations it is usual to require only 1 STOP bit, where the line must remain idle. If one UART is set for 1 STOP bit and the other is set for 2 STOP bits there will be problems. Review your settings on both ends of the link.

 

Framing error on the PIC or PC?

If PIC, are you using a custom EUSART driver or a provided library?

Can you show code for your EUSART driver and/or calling function?

 

i have not set any cts/rts setting.. stop bits is set to 1 on both devices.

 

i have not set any cts/rts setting.. stop bits is set to 1 on both devices.

Without more information I'd have to say you're just SOL.

 

wat info u need?

 

It might help if you post the initialization routine(s) and the code fragments that deal with transmitting and receiving data.

Also, is this a problem in both directions or one only?

Let's keep in mind that unlikely as it may seem, it is too early to rule out this being a hardware problem.

 

I am trying to communicate my PC(master) with microcontroller PIC18f45k22(slave) using uart protocol(rs232). Slsve accepts query from PC and also response correctly the first time, but when PC sends query the second time a framing error occurs. i am really stuck up here. somebody please help me out?

Hi, I don't know if you are using the receive interrupt at the PIC but when to slow it could produce problems.
Test1: Make a delay between the character to send one transmission byte time if this solves your problem look at your input mechanism.
Test2:clear input buffer after receive ( perhaps already done ).
Advice: make sure that an input is not generating an output interrupt without ( eq echo char in receive interrupt routine)
Picbuster

 

here's my routine
//============ GSM port2 =======================================================
if (RC2IF) //RX int
{
RC2IF=0;
//****
if (RCSTA2bits.OERR) // check for overrun.
{
RCSTA2bits.CREN=0; // clear receiver
RCSTA2bits.CREN=1; // re-enable
Port2Pointer=0;
}
Input_C = RCREG2;
if (Input_C==Block_Terminator){Port2In = On;} // set reveive flag Block_terminator (eq eot / cr / whatever you like)
Port2String[Port2Pointer]=Input_C;
Port2Pointer++;
if (Port2Pointer>=350){Port2Pointer=0;} // oops more chars then buffersize (swing away the lot)
//****

}
//-----------------------------------------------------------------------------
// Port2In blok reveived Port2Pointer received chars
// carefull this is solid software have duplex (while Port2In is true data could be added to port2string and blow up the existing Port2Pointer)
// to overcome this use receive flag to delete incomming chars. if (!Port2In) execute between //****

 

Hey I did get framing errors in the USART when I started with 18F.
I used the default mikroC lib's.

After a lot of trying and pain staking changes nothing helped but it worked when I changed the "HFINTOSC Fast Start-up" to Enable, at "CONFIG" . Before it was Disabled.
Now it works without a problem .

 

Hi, I don't know if you are using the receive interrupt at the PIC but when to slow it could produce problems.
Test1: Make a delay between the character to send one transmission byte time if this solves your problem look at your input mechanism.
Test2:clear input buffer after receive ( perhaps already done ).
Advice: make sure that an input is not generating an output interrupt without ( eq echo char in receive interrupt routine)
Picbuster

Hi, I have used Receive interrupt at pic. Already tried Test2 but didn't help. Can you please elebroate on Test1 and the Advise.

 

Hi, I have used Receive interrupt at pic. Already tried Test2 but didn't help. Can you please elebroate on Test1 and the Advise.

This is a modification @ PC site.
PC send one byte and wait 1mS before sending the next one allowing the receiver in the PIC to collect al bits in your byte.
An other point to look at is the baud rate not all xtal frequencies will support all baudrates (see baud rate table in manual)
I send a complete working code @ Tuesday use this for testing.

20Mhz pic18F8722
//================= port2 set-up ============================
RCSTA2=0b10010000;
TXSTA2=0b00100100;
SPEN2=1;
SYNC2=0;
BRGH2=0;
SPBRG2 =15; // 19K2 baud
//======================= ===========================
Picbuster

 

here is what is happning exactly, when i send this query 01 03 0000 0001 crc communication is established properly and that to any number of times. 01 03 0000 0002 crc also works properly but as soon as i send 01 03 0000 0003 crc the communication takes place only once and than the second time an FERR Error occurs.

(Note: =I am using an modbus master software on my PC to communicate with my PIC (Slave) so the problem is on the slave side)

 

Problem: when sending then 01 03 00000 0002 thing no problem even when send n times is this correct?
then sending 0003 crc the systems generate a error correct?
you are able to reproduce this correct?

a: monitor your line are there a bunch off non printable chars running over the wire when sending this 0003 thing?
b:I do get the impression that there is an other problem if all in above are correct.
what is your mpu going to do when this 003 arrives occupying mpu or blowing up a variable or stack ?
Question how do you know for sure that this is a framing error and not a mishap in error detection?

Picbuster

 

transmission is workin

Problem: when sending then 01 03 00000 0002 thing no problem even when send n times is this correct?
then sending 0003 crc the systems generate a error correct?
you are able to reproduce this correct?

a: monitor your line are there a bunch off non printable chars running over the wire when sending this 0003 thing?
b:I do get the impression that there is an other problem if all in above are correct.
what is your mpu going to do when this 003 arrives occupying mpu or blowing up a variable or stack ?
Question how do you know for sure that this is a framing error and not a mishap in error detection?

Picbuster

YES. No problem if i send 01 03 0000 0002 crc n number of times.
when i send 01 03 0000 0003 crc, FERR error occures(the second time).
you are able to reproduse this? - i did not understand this.
0003 is the no. of holding register to be read. so the microcontroller will read 3 holding registers values starting with address 0 and send the response.
if have kept an LED for indicating FERR error.

 

reproduce I mean this will always happen when you repeat the same procedure.
question: what is the status of all registers and variables after the first .......0003 crc is received.
Is there a input buffer pointer for the 0003 message is this one cleared?
Next thing transmit buffer 0003 will send data when not defined properly( to small) the pointer goes somewhere and could overwrite things resulting in a strange unrealistic error.

Picbuster