Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[SOLVED] PIC serial port receive Problem, please help

Status
Not open for further replies.

thunderboympm

Full Member level 5
Joined
Sep 17, 2007
Messages
243
Helped
32
Reputation
64
Reaction score
29
Trophy points
1,308
Location
Malappuram, India
Activity points
2,469
hai,
I am reading the return back from a GSM Module (SIM900A) using PIC18f452, the module is AE GSM MODULE. the problem is when I am connecting the GSM module through the ft232 module by serial GSM modem is working, and also my program is also OK, but when I am connecting to the AE GSM MODULE the program is not getting the return back. anyone has faced similar problems and can anyone give any clues.
8-O8-O
 

Hi,

I don't understand:
* when you say you use ft232, then your PIC needs to have an USB_host to operate it.
If it does work with FT232, then why not use it this way?

but when I am connecting to the AE GSM MODULE
Connecting what to the GSM module?

A simple (hand drawn) sketch of the two situations (working and not_working) could be useful.

I assume you already read some UART troubleshooting threads here. Then you already should know that in 95% of the cases the problem is:
* wrong interface setting (baud rate, baud rate tolerance, bits per byte, start bits, stop bits, parity, handshaking...)
* or wrong voltage levels.
--> but you don't give none of the above informations.

Klaus
 

Are you confusing FT232 and MAX232 perhaps?

FT232 = serial to USB converter
MAX232 = Voltage level converter usually used in serial TTL to RS232 applications.

Normally you don't need a voltage level converter between GSM modules and a PIC and you should also be aware that if it is a MAX232 it inverts the signal and could result in voltages that can damage one or both connected devices.

Brian.
 

Hi,

I don't understand:
* when you say you use ft232, then your PIC needs to have an USB_host to operate it.
If it does work with FT232, then why not use it this way?


Connecting what to the GSM module?

A simple (hand drawn) sketch of the two situations (working and not_working) could be useful.

I assume you already read some UART troubleshooting threads here. Then you already should know that in 95% of the cases the problem is:
* wrong interface setting (baud rate, baud rate tolerance, bits per byte, start bits, stop bits, parity, handshaking...)
* or wrong voltage levels.
--> but you don't give none of the above informations.

Klaus
Thanks for reply sir,
My problem is when I am connecting my pic(pic18f452) to GSM module using serial port at a board rate of 9600, pic producing OERR, that causes data loss. I am getting good results in pc.

- - - Updated - - -

Are you confusing FT232 and MAX232 perhaps?

FT232 = serial to USB converter
MAX232 = Voltage level converter usually used in serial TTL to RS232 applications.

Normally you don't need a voltage level converter between GSM modules and a PIC and you should also be aware that if it is a MAX232 it inverts the signal and could result in voltages that can damage one or both connected devices.

Brian.

Thanks for reply sir,
My problem is when I am connecting my pic(pic18f452) to GSM module using serial port at a board rate of 9600, pic producing OERR, that causes data loss. I am getting good results in pc
 

OERR means overrun error, a new character arrived before the UART buffer has been read. Apparently your code isn't able to process the data in time. Did you consider an interrupt driven RX ring buffer?

A trivial point is that your code should monitor UART errors, e.g. OERR, and reset it if they occur sporadically.
 

OERR means overrun error, a new character arrived before the UART buffer has been read. Apparently your code isn't able to process the data in time. Did you consider an interrupt driven RX ring buffer?

A trivial point is that your code should monitor UART errors, e.g. OERR, and reset it if they occur sporadically.
Sir, I am resetting OERR and giving a NOP period.

- - - Updated - - -

OERR means overrun error, a new character arrived before the UART buffer has been read. Apparently your code isn't able to process the data in time. Did you consider an interrupt driven RX ring buffer?

A trivial point is that your code should monitor UART errors, e.g. OERR, and reset it if they occur sporadically.


Code C - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
void __interrupt() ISR(void){
    GIE = 0;
    if(RCIF){
        RCIF = 0;
        GSMtemp = RCREG;
        if(GSMtemp == '+'){
            plusFlag = 1;
            GSMindex = 0;
        }
        if(plusFlag){
            GSMbuff[GSMindex] = GSMtemp;
            GSMindex ++;
        }
        if(GSMtemp == 'K')
            OKFlag = 1;
        if(OERR){
            CREN = 0;
            NOP();
            CREN = 1;
        }
    }
    GIE = 1;
}


This is my interrupt subroutine
 

Remove the two lines that contain 'GIE', they are not needed and could cause other problems including possible 'deaf' periods where serial data is lost.

I think you are trying to capture all the characters between '+' and 'OK' but you face two problems, the first is no check for the data overflowing the size of 'GSMbuff' and other is it will fail if 'K' appears in the data before it is used as the terminator.


Brian.
 

Remove the two lines that contain 'GIE', they are not needed and could cause other problems including possible 'deaf' periods where serial data is lost.

I think you are trying to capture all the characters between '+' and 'OK' but you face two problems, the first is no check for the data overflowing the size of 'GSMbuff' and other is it will fail if 'K' appears in the data before it is used as the terminator.


Brian.
Sir, I made a buffer GSMbuff of 80.
Actually my application was to capture the terminal messages after I giving the command at+cnmi=2,2,0,0,0. So the message will suddenly send to terminal with a format with a starting of +CMT:.........
I made a code for this and successfully simulated and tested successfully in hardware (by connecting to pc). But when I connecting to GSM module the problem arises...
 

I made a code for this and successfully simulated and tested successfully in hardware (by connecting to pc). But when I connecting to GSM module the problem arises.
That's a bit more of information.

1. There may be a hardware problem, e.g. wrong or incomplete connection of the modem module, missing handshake lines etc.

2. In any case, it's useful to think about debugging options. I prefer to have two UART-to-TTL channels to capture RX and TX data in a PC application. You may also use a PIC hardware debugger to trace code operation, e.g. content of the receive buffer.

All in all, it's just regular embedded developing work. Code runs rarely at first try.
 

That's a bit more of information.

1. There may be a hardware problem, e.g. wrong or incomplete connection of the modem module, missing handshake lines etc.

i am not using any handshake lines, only RX -> TX, TX -> RX, and GND -> GND
 

Yes, but modem may need a certain wiring of handshake lines. As previously mentioned, without some debugging means you can only guess.
 

do need more of debugging to get the solutions else its just gona be random guessing
 

That is because in Proteus Virtual Terminal "\r\n" is not sent and you cannot send it. In real hardware the GSM commands and responses will contain one or more pairs of "\r\n".
 

Nothing has been said about Proteus simulation in this thread. As far as I understand, thunderboympm is reporting real hardware tests.
 

I made a code for this and successfully simulated and tested successfully in hardware (by connecting to pc). But when I connecting to GSM module the problem arises...

He mentions simulated.
 

Yea sir,
I simulated it correctly in Proteus, and I fused the program through pikit3 to pic. And in hardware I send GSM returns though serial port (using ft232). At that time it is working as in my simulation in Proteus. But when I am connecting to GSM module the program is not working...
 

Why don't you reserve a 200 or 300-byte buffer and receive the whole GSM response data for a command and then parse it and do whatever is needed?
 

At that time it is working as in my simulation in Proteus.
But when I am connecting to GSM module the program is not working...

It has to be asked: Are you simulating exactly with the same 'AT' sentences used with a previously tested manual connection? If so, it is most likely a matter of timing, which could be avoided by using the flow control mentioned before.

As per the sippet you posted, it is almost senseless. Was your intent is to decode some specific sentence on the fly? Seems like you wanted to check reception of both '+' and 'K' characters not in sequence, the if's are not cascaded with else's, so any other incoming character - garbage or not (as expected on real world) would make your code act erratically (e.g: After evaluating plusFlag as true, you do not take any action otherwise) .

Just a tip: Try to simulate and validate each part of the code incrementally, not the whole, so that you can determine at what stage of the 'conversation' among microcontroller and Modem it fails.
 

It has to be asked: Are you simulating exactly with the same 'AT' sentences used with a previously tested manual connection? If so, it is most likely a matter of timing, which could be avoided by using the flow control mentioned before.

As per the sippet you posted, it is almost senseless. Was your intent is to decode some specific sentence on the fly? Seems like you wanted to check reception of both '+' and 'K' characters not in sequence, the if's are not cascaded with else's, so any other incoming character - garbage or not (as expected on real world) would make your code act erratically (e.g: After evaluating plusFlag as true, you do not take any action otherwise) .

Just a tip: Try to simulate and validate each part of the code incrementally, not the whole, so that you can determine at what stage of the 'conversation' among microcontroller and Modem it fails.
Sir, as per the whole consideration.
Code:
void __interrupt() ISR(void){
    
    if(PIR1bits.RCIF){
        if(RCSTAbits.OERR){
            RCSTAbits.CREN = 0;
            NOP();
            RCSTAbits.CREN = 1;
        }
        GSMbuff[GSMindex] = RCREG;
        GSMindex++;
        gsmFlag = 1;
    }
}
This is my modified interrupt subroutine
Code:
while(1){
        if(gsmFlag){
            while(1){
                if(GSMbuff[GSMindex - 1] == EOD){
                    gsmFlag = 0;
                    break;
                }
                if(GSMindex >= MAX_BUF_LEN)
                    break;
                STAT = !STAT;
            }
This is the code sippet in my main program

have EOD as '*' and MAX_BUF_LEN as 200 .
GSMbuff is a char array of size of 200.STAT is a LED.

Still the results are same.
 

Don't forget that the UART Rx baud rate must be within +/-2% of whatever the sender is using. You have not shown us the UART setup and the CONFIG settings, nor what the Fosc is that you are using.
I am pleased to see that you are reducing the size of the ISR and moving the parsing into the main line. However I would recommend that you check for the terminator character (probably '\n or whatever the last character is on the line sent by the GSM module) and trigger the parsing on that; not on every character received. the advantage of this approach is that you can scan from the first received character to find the '+' which starts the response (thus skipping over any trailing characters - one document I read just now shows that the GSM module ends and "OK" line after the response), interpret the received characters until you get to the line terminator. You should have all of the characters in the buffer and not need to do the parsing a bit at a time.
Also, you probably should read up on how to properly do the parsing. Parsing even well documented strings such as these is not trivial (specialise when you need to take into count all sorts of variations within each response string sad well as incomplete messages and errors) and it is very easy to do the job really badly. Bad code will work for a while (perhaps long enough to get a 'pass' mark for an assignment) but will fail in time.
Susan
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top