 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
| PIC keeps reseting, UART does not receive, PIC BBQ soon! |
 Posted: Mon Aug 03, 2009 3:29 pm |
 |
|
Hi all,
I'm new to the board, joined in hopes of finding some help, and if possible giving some.
I'm not new to PICs, but its been 2 years since I last tackled a real project. I'm a bit rusty.
To the point:
My project is an SMS controlled sensor (I know I'm super original).
I'm using a SE T290a with a DRS11 cable.
On a custom PCB I made, with onboard 7805, max232... etc (want one?)
running a PIC16f877A @ 20mhz (ceramic resonator).
My PIC keeps resetting, sometimes it won't start (simulates death quite nicely) , runs a few times and then goes insane, I touch the board and hell breaks loose. You get the picture.
But that's not all... hehehe.
As a general rule, I start small with my projects... so
I started to by testing my serial com, using hyperterminal... and it works.
Wrote a simple echo program to test my hardware... worked perfect.
I tested the phone with my pc and it worked perfect as well.
I wrote a simple program to test communication PIC-->Cell
which mimics my keystrokes on hyper terminal.
All the program did was turn on a led if the cellphone responded with an 'OK' to the AT command.... it didn't work.
And now, my PIC can send but not receive data.
Same echo program used to test the hardware which worked before
does not work now.
I thought I fried a chip, so I got another one and now I have 3 '877As' who talk but don't listen..... even though the code didn't change.
I will post my code when I get home. I'm at work.
Help? I know there are multiple issues here. Any help on any of them is welcomed.
Thanks
gabriel
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 03, 2009 4:02 pm |
|
|
| Quote: |
My PIC keeps resetting, sometimes it won't start. I touch the board and
hell breaks loose.
|
Primary reasons:
1. Bad MCLR circuit.
2. Bad power or ground connections.
3. Bad crystal circuit.
4. Bad power supply - not regulated.
Secondary reasons:
5. Incorrect fuse settings for oscillator, brownout, WDT, etc.
6. Lack of bypass capacitors on Vdd pins on the PIC.
7. Large noise spikes on Power/Ground pins or other pins.
8. Carpet in your room causes static charge build-up on you. |
|
|
Guest
|
|
| Posted: Mon Aug 03, 2009 4:18 pm |
|
|
Hello, thanks for responding so fast.
I'm using a 220AC/13DC wallwart connected to a 7805 5v reg.... I have "large" caps on both input and output.
I have a 10k pull up on MCLR in series with a diode.
5V ---> 10k ---> Diode --->MCLR
I'm using a Ceramic 20MHz resonator.
I'll post my code in less than an hour and a bit more circuit details when I have my board in my hand.... hopefully you can check it out.
I do have a carpet, it is winter down here so ... static is a possibility.
I placed my board on top of a neoprene pad, I guess that didn't help hehe.
The circuit is completely stable as far as I could notice when I was in Panama, started to go insane in Argentina.
Probably because of the humidity.
Thank you for your help
gabriel |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 03, 2009 4:23 pm |
|
|
| Post a schematic and a photo of your entire board. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Mon Aug 03, 2009 5:06 pm |
|
|
Hi PCM,
Can't post a picture yet, but I will first thing tomorrow!
Anyways I tried some of the stuff you suggested... and well..
the erratic behavior has been arrested... it was the fuses..
now my chips talk and listen as well.
So now my problem has been reduced to the fact that my cellphone does
not answer to a simpe "AT" command.
The code below, simply sends the strings "AT" & '\r'
When I try responding like the cellphone does over hyper terminal it works like a charm, but when its time for the cell to do the answering...
it seems like the PIC doesn't get the expected string. So no response.
The cellphone answers:
| Code: |
"AT
OK
"
(AT\r\nOK\r\n)
|
| Code: |
#if defined(__PCB__)
#include <16f877a.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP,NOBROWNOUT,NOPUT
#use delay(clock=20000000) //must be 20 MHz
#elif defined(__PCM__)
#include <16f877a.h>
#fuses HS,NOWDT,NOPROTECT,NOLVP,NOBROWNOUT,NOPUT
#use delay(clock=20000000) //must be 20 MHz
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7) // serial
void SerialInt(); // USART INT handler
Void TEST_AT(); // Test Modem
int counter=0; //general purpose counter
Char Recieve_String[12]; //buffer for incomming data
void main()
{
SET_TRIS_A( 0x00 ); // to avoid floating pins
SET_TRIS_B( 0x00 );
SET_TRIS_C( 0x80 );
SET_TRIS_D( 0x00 );
SET_TRIS_E( 0x00 );
enable_interrupts(INT_RDA); // enable RDA interrupts
enable_interrupts(GLOBAL); // enable global ints
while(1)
{
output_high(PIN_D1); // blink for 'ON' confirmation
delay_ms(500);
output_low(PIN_D1);
delay_ms(500);
output_high(PIN_D1);
delay_ms(500);
output_low(PIN_D1);
TEST_AT(); // TEST FOR 'OK' response
}
}
Void TEST_AT()
{
counter=0;
printf("AT"); //send command
printf("\r"); //send return ('enter' in hyperterminal)
While(counter<7) //"A T \R \N O K \R \N" characters returned by modem
{
}
counter=0;
while((Recieve_String[counter]!='O')&&(counter<10)) //check buffer until an 'O' is found or 10 chars have been checked.
{
counter++; //obvious
}
if((Recieve_String[counter]=='O')&&(Recieve_String[counter+1]=='K')) //check for a 'K' after the 'O'
output_high(PIN_D1); //light a led if "OK" is encountered
delay_ms(1000); //delay de un segundo, cualquier caracter una ves confirmado el ok (o si no es ok) ke entre al uart en este perido sera ignorado
output_low(PIN_D1); // this is just to give me enought time so see the led actually turn on.
}
#INT_RDA
void SerialInt()
{
Recieve_String[counter]=getchar();
counter++;
}
|
Sorry for the delay, I took the time to translate my program comments.
Thank you so much... you've taken hours of frustration off of my shoulders.
g
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Aug 03, 2009 6:09 pm |
|
|
I don't have any experience with SMS commands. Someone else will
have to help you with the rest of it. |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Tue Aug 04, 2009 5:35 am |
|
|
PCM,
Thank you very much for your help.
gabriel
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Aug 04, 2009 7:33 am |
|
|
| Anonymous wrote: | Hello, thanks for responding so fast.
I'm using a 220AC/13DC wallwart connected to a 7805 5v reg.... I have "large" caps on both input and output.
I have a 10k pull up on MCLR in series with a diode.
5V ---> 10k ---> Diode --->MCLR
I'm using a Ceramic 20MHz resonator.
I'll post my code in less than an hour and a bit more circuit details when I have my board in my hand.... hopefully you can check it out.
I do have a carpet, it is winter down here so ... static is a possibility.
I placed my board on top of a neoprene pad, I guess that didn't help hehe.
The circuit is completely stable as far as I could notice when I was in Panama, started to go insane in Argentina.
Probably because of the humidity.
Thank you for your help
gabriel |
First. 'Large caps on both input and output'. Unless you have a reverse biased diode across the regulator, this is a very good way to kill a 7805...
Then, how close to the 7805, is the capacitor on the output?. Have you any _small_ caps on the rails as well?. The problem is that electrolytic capacitors, have very poor HF response. If you only have a 'large' capacitor on a rail, you may have almost nothing blocking high frequencies. If the output capacitor is large, it may also make supply regulation worse. You need something like a 0.1uF ceramic, or polyester _close to the regulator_ on the output, paralleled with perhaps 100uF, and another 0.1uF, _close to the PIC_. Also similar small capacitors close to any circuitry involving high frequency switching. You may well have the regulator oscillating....
Second,. the 'series diode', is not a good way to drive MCLR. The pin is basically left floating, when you switch off, rather than being pulled down. Small capacitor from MCLR to ground. Resistor from MCLR to +5v, _paralleled_ with a reverse biased diode. This way, MCLR rises shortly after power comes on (determined by the time constant othe resistor and capacitor), but is shorted out _quickly_ when the power rail falls.
Best Wishes |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Tue Aug 04, 2009 8:03 am |
|
|
| Quote: | | I have "large" caps on both input and output. |
By large... I mean I have enough filtering capability....I know I can kill my supply with the initial current rush of an empty capacitor...my regulator is steady at 4.92v.
I also have a 0.1 tantalum polarized cap.. on my rails about ~1.5cm from my power pins on the chip..... for HF filtering.
About the capacitor on MCLR... yeah.. you got me there...I'm not sure if it should be polarized ... like the tantalum.... or just a regular ceramic cap.
I got my MCLR schematic from the an ICSP application note on Microchip.com
but, left the cap out....because....I have no idea. Guess I spaced out.
Anyways.... I will correct the MCLR issue asap... even though its working properly now...(the erratic behaviour part..) it was just some missing fuses....like I said... I'm a bit rusty.
Thanks for your help
g
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Ttelmah
Guest
|
|
| Posted: Tue Aug 04, 2009 8:10 am |
|
|
It is not the initial inrush, but the reverse current through the regulator, when you switch off. If you have reasonable levels of reservoir on the output, and circuitry that doesn't draw very much (things like PICs....), the 5v rail can remain 'high', after the input drops. This can result in reverse current through the regulator, which it can't take. Phut.....
If there is more than a relatively few uF on the output rail, you must put a diode across the regulator to handle this.
Best Wishes |
|
|
Jerson
Joined: 31 Jul 2009
Posts: 122
Location: Bombay, India
|
|
| Posted: Tue Aug 04, 2009 8:21 am |
|
|
Hi Gabriel
Like you, I am new to this board. However, I have behind me lots of working designs and thought I can offer a few tips.
1) When using radios proper shielding(guess you already knew that) is mandatory. A full ground plane is preferred
2) Check the rating of your power supply. Is it able to deliver the peak current demanded by your circuit? When you use hyper term, this will reduce since the GSM module is out of the circuit (my assumption)
3) You seem to have 'global'ised the counter(haha). This way the Test_AT routine will destroy any late characters that may be coming into the serial ISR. Separate them out as Counter_ISR and Counter maybe.
And yes, a schematic will help diagnose better. Still better, a picture speaks a thousand words.
Good luck
Jerson
_________________
Regards
Jerson Fernandes |
|
|
Gabriel
Joined: 03 Aug 2009
Posts: 1067
Location: Panama
|
|
| Posted: Tue Aug 04, 2009 8:49 am |
|
|
hey jerson,
I'm using a wall wart with a 7805.... my wallwart is 250AC-13DC rated at 500mA... I'm pretty sure thats enough to cover a 16F877A and a MAX232, and a LED(for debugging).
The cellphone runs on its own power supply and/or internal battery so its power demands are covered separately.
I don't seem to understand how my counter affects any late characters....
the counter you see.... is the only counter... for only one purpose... get the data.
I've taken care to not overwrite data... or change the counters value during acquisition.
But... I might be missing something... care to explain?
I posted the code for review... so I am open to sugestions... and if I made a mistake.... please feel free to correct me.... I'm here cause I need help.
Thank you for your help... I'll know who to ask questions when I actually get to transmit something with the cellphone and it starts to interfere with my circuit! Cellphones interfere with almost any device I have in my house... ( I can hear I'm getting a call before it rings).... I'm sure my pic will not like the RF from the cell either.
_________________
CCS PCM 5.078 & CCS PCH 5.093 |
|
|
Jerson
Joined: 31 Jul 2009
Posts: 122
Location: Bombay, India
|
|
| Posted: Tue Aug 04, 2009 9:08 am |
|
|
| Quote: | Void TEST_AT()
{
counter=0;
printf("AT"); //send command
printf("\r"); //send return ('enter' in hyperterminal)
While(counter<7) //"A T \R \N O K \R \N" characters returned by modem
{
}
counter=0;
while((Recieve_String[counter]!='O')&&(counter<10)) //check buffer until an 'O' is found or 10 chars have been checked.
{
counter++; //obvious
}
if((Recieve_String[counter]=='O')&&(Recieve_String[counter+1]=='K')) //check for a 'K' after the 'O'
output_high(PIN_D1); //light a led if "OK" is encountered
delay_ms(1000); //delay de un segundo, cualquier caracter una ves confirmado el ok (o si no es ok) ke entre al uart en este perido sera ignorado
output_low(PIN_D1); // this is just to give me enought time so see the led actually turn on.
} |
Ok, the power supply doubt is out.
The 'counter' point made by you is valid. In case the characters come after the 7 you are looking for, .....
See the red code. Is it possible that you are getting more than the expected characters? I can recommend, you simply display the counter value after a reasonable delay of 3 seconds to be sure.
How about doing this in the Test_AT?
| Code: | while (counter < sizeof(Receive_String)-1 )
{
if ( (Recieve_String[counter]=='O'
&& (Receive_String[counter+1]=='K') )
{
// found 'OK' so,
// blink the OK led
break; // out of the while loop
}
else
counter++;
} |
_________________
Regards
Jerson Fernandes |
|
|
Guest
|
|
| Posted: Tue Aug 04, 2009 9:54 am |
|
|
Jerson... you are a genius
I can't test it right now cuzz I'm at work but this is what you made me see:
In my code, as shown below once I reach 7 characters immediately start checking for the OK because its already there... BUT!
If the code gets past the counter initialization and manages to do one or more comparisons before the last character comes, my counters get scewed and the check fails or something is overwritten
This is solved by simply adding a 500ms? delay after the second "counter=0;" ? Don't you think? To allow the transmission to complete and to "properly" ignore all remaining characters since I don't know the actual number of characters. Once I do, I'll change the 7 in the while loop for the appropriate value.
What do you think? I think thats it.
| Code: | Void TEST_AT()
{
counter=0;
printf("AT"); //send command
printf("\r"); //send return ('enter' in hyperterminal)
While(counter<7) //"A T \R \N O K \R \N" characters returned by modem
{
}
counter=0;
while((Recieve_String[counter]!='O')&&(counter<10)) //check buffer until an 'O' is found or 10 chars have been checked.
{
counter++; //obvious
}
if((Recieve_String[counter]=='O')&&(Recieve_String[counter+1]=='K')) //check for a 'K' after the 'O'
output_high(PIN_D1); //light a led if "OK" is encountered
delay_ms(1000); //delay de un segundo, cualquier caracter una ves confirmado el ok (o si no es ok) ke entre al uart en este perido sera ignorado
output_low(PIN_D1); // this is just to give me enought time so see the led actually turn on.
} |
Thanks
Gabriel |
|
|
Jerson
Joined: 31 Jul 2009
Posts: 122
Location: Bombay, India
|
|
| Posted: Tue Aug 04, 2009 10:35 am |
|
|
| Anonymous wrote: | Jerson... you are a genius
thanks
Gabriel |
Thanks. The first certificate on this site  ) Glad to help.
Usually, I wait for a response time before I start checking. Works for RS232, RS485 too. You can see what works for you or simply flag the receipt of the \r character as a buffer ready condition from the ISR. That will signal you to check the buffer in Test_AT. However, your ISR should account for the counter exceeding buffer size.
Best
_________________
Regards
Jerson Fernandes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
