| View previous topic :: View next topic |
| Author |
Message |
vminin
Joined: 05 Feb 2009
Posts: 8
|
| Serial port doesn't work long enough |
 Posted: Fri Feb 06, 2009 1:13 pm |
 |
|
I have a situation here. I run the program which receives a few characters from PC and sends a pocket of data back to PC. It works perfect but from time to time it stops receiving command from PC. Turning power off/on on microcontroller side helps to reset the program ( I ran the program under debuger and neither halt/go nor reset button wouldn't help, only turning power off helps)
Here is the test program:
| Code: |
#include <stdlib.h>
#use delay(clock=30000000)
#use rs232(baud=115200,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
//hardware flow control
#define CTS PIN_C5
#define RTS PIN_C4
char string[8];
int32 number = 0;
int16 count = 0;
char c = '0';
int i = 0;
#int_rda
void serial_isr()
{
c = getc();
}
void main()
{
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_spi(SPI_SS_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
enable_interrupts(int_rda);
enable_interrupts(GLOBAL);
output_low(RTS); //
while(1)
{
while(c != '2')
;
output_high(RTS);
while(input(CTS))
;
putc('\n');
while(input(CTS))
;
putc('\r');
do
{
while(input(CTS))
;
putc('1');
}while(count++ != 800);
number++;
string[0] = '-';
itoa(number,10,string+1);
do
{
while(input(CTS))
;
putc(string[i]);
i++;
}while(string[i] != '\0');
i = 0;
output_low(RTS);
count = 0;
c = '0';
}
} |
Pic18F252
I use serial port minitor with the macro running:
Command(hex) : 4545454532
Repit : checked
Milliseconds : 200
Any ideas? |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 06, 2009 1:27 pm |
|
|
| Quote: | | It works perfect but from time to time it stops receiving command from PC. |
I didn't look closely at your program with all your CTS stuff. Looking
at other things, I have these comments:
1. Add the ERRORS parameter to your #use rs232() statement.
If lock-ups are caused by receiver overrun errors, this will clear the
errors and prevent lockups.
2. The Picbaud program shows a difference of 1.73% from the ideal
115200 baud rate, with your 30 MHz clock. That's not the best.
Possibly it could be a source of error.
http://www.ccsinfo.com/forum/viewtopic.php?t=37250&highlight=picbaud |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Fri Feb 06, 2009 1:39 pm |
|
|
Thanks for quick reaction!
CTS/RTS things are not important, they work as needed.
Yes, i have the error statement in my real program and it doesn't help to much. Any way I will add this in my sample program.
I know, that 1.73% is a bit to much, but in your post you said it should be less then 2%... Well, i will change it either.
Program stops with no reason. There is no pattern, it could be after 5 minutes or after couple hours... |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 06, 2009 1:54 pm |
|
|
What's the purpose of your program ?
Is it being run in a simulator, or in hardware ? If a simulator, post
which one you're using.
Also, post your #fuses statement. |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Fri Feb 06, 2009 2:03 pm |
|
|
It runs in hardware.
Here is fuses:
| Code: | #include <18F252.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES HS //Resistor/Capacitor Osc
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOOSCSEN //Oscillator switching is disabled, main oscillator is source
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES NOPUT //No Power Up Timer
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NODEBUG //No Debug mode for ICD
#FUSES LVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOCPD //No EE protection
#FUSES NOCPB //No Boot Block code protection
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads |
|
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 06, 2009 2:14 pm |
|
|
This setting can certainly cause random lock-ups. Change it to NOLVP.
Do that in all your programs. |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Fri Feb 06, 2009 2:24 pm |
|
|
Thanks PCM!
I will change and try, then post result. It would take awhile though:) |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Mon Feb 09, 2009 10:46 am |
|
|
I changed to #FUSES NOLVP, replaced the crystal, now it is 24MHz, set BRGH = 1, SPBRG = 12 (error 0.16%).
By the way, real freq from original crystal 30MHz was 29.77. I checked with PicBaud, the error was .95%
Any way, didn't help.
After about 3 hours it is crashed.:(
replaced 18f252 by new one. all the same.
Under debuger it takes some time to stop program. When I click on Stop, i could see the string "Reading RAM" for about 2min in debuger window status line.
Any ideas? |
|
|
drh
Joined: 12 Jul 2004
Posts: 192
Location: Hemet, California USA
|
|
| Posted: Tue Feb 10, 2009 9:20 am |
|
|
The documentation is confusing but the maximum frequency xtal you can use is 25Mhz. If you want to use 30Mhz, you would need an external oscillator module with the EC or EC_IO fuse.
_________________
David |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Tue Feb 10, 2009 9:55 am |
|
|
What is the last output from the pic when it stops ?
There is a fault with your code but you may never see it.
number is an int32
string is only 8 chars long.
The '-' is 1 char
the '\0' is 1 char
so if number ever reaches 1000000 it will overrun the array and this will most likely corrupt number. |
|
|
Guest
|
|
| Posted: Wed Feb 11, 2009 5:13 pm |
|
|
drh: The documentation points that it was tested with the combinations resonator + capacitors at 25MHz. But the pic would work up to 40 MHz. I have the same set in my previous application which has worked via USB for about 5 years (may be less  ) very stable. So this is not a reason.
Wayne_ :
-number is an int32
-string is only 8 chars long.
-The '-' is 1 char
-the '\0' is 1 char
-so if number ever reaches 1000000 it will overrun the array and this will
-most likely corrupt number.
Yes, I know. But the number is so big! for my application it would take about 3 month to hit this number:) It failed at the most -92455 after about 6 hours running.
I replaced PIC18F252 by PIC18F2520. Almost 8 hours has passed, it is still running... The data is corrupted though... this is another story, I don't care for now.
The funny thing, under Debugger the BRGH is set to 1 from beginning, but I didn't set it... |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Thu Feb 12, 2009 8:57 am |
|
|
| sorry, I was log in as a guest above |
|
|
Wayne_
Joined: 10 Oct 2007
Posts: 681
|
|
| Posted: Thu Feb 12, 2009 10:12 am |
|
|
| Anonymous wrote: | drh:
The data is corrupted though... this is another story, I don't care for now.
The funny thing, under Debugger the BRGH is set to 1 from beginning, but I didn't set it... |
What data is corrupt ?
The data being output by the PIC and displayed on the terminal over RS232 ?
If it is the serial data then how do you know that you are not eventually sending corrupt data (command string) which is why it is not behaving as expected ? |
|
|
Ttelmah
Guest
|
|
| Posted: Thu Feb 12, 2009 10:12 am |
|
|
I'd suggest that you get your oscillator into spec.
Bsically, any time you work 'out of spec', you are asking for problems. Now the 252, is an older 'core' than the 2520, and is less likely to work 'beyond' the data sheet ratings. I'd say this is what you are seeing. Working beyond data sheet ratings, is a sure way to design unreliable equipment. Even with the 2520, it is likely that the kit will go wrong, at higher temperatures, or lower supply voltages.
Use the internal PLL, so you can operate the chip faster with a slower oscillator. This then gives operation inside the ratings, _and_ reduces EMI as well. A useful bonus.
Best Wishes |
|
|
vminin
Joined: 05 Feb 2009
Posts: 8
|
|
| Posted: Thu Feb 12, 2009 1:53 pm |
|
|
Wayne_ : Never mind. It was my fault, I played with code and forgot uncomment CTS/RTS stuff:
// while(input(CTS))
// ;
// delay_us(2);
putc('1');
sorry about that.
Ttelmah: I use the same crystal as a source of frq in the other part of my application. So I am kind of limited by 20MHz at the lower end and 30MHz at the higher. So, the PLL would be the last thing I would like to do. I would rather try to solve the problem with the current layout. Would you recommend a crystal 25Mhz as beeing in the spec? Thanks in advance |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
