 |
 |
| View previous topic :: View next topic |
| Author |
Message |
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
| Reset vs. Power-Up (Power Cycle) Serial Interrupt issues |
 Posted: Tue Jan 26, 2010 10:14 am |
 |
|
Hello everyone. I'm nearing the end of my project and I have been plagued by this trouble for quite sometime, finally decided to post and see if anyone could offer any suggestions. I've looked on the net and this forum, but I don't think I'm using the right keywords in the search.
I've written a program on a 18F4520 - seems to work well, until I cycle the power supply on and off. The hardware serial power stops functioning (the interrupt). When I press the reset button on the development board, the circuit functions properly once again.
I decided not to post the code at this time because it's a little messy (so I'm a little embarrased - I'm new at this) and I have a feeling this is a problem others have experienced in the past.
I am using a PICDEM 2 Board from Microchip, an 18F4520, Maxim RS232 level, a GSM modem (serial), a 9V power supply. Seems to run until I disconnect and reconnect the power. Pressing reset is required for the program to function again. I hope I didn't miss anything.
Thanks in advance for any suggestions you can provide me with. |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Jan 26, 2010 10:43 am |
|
|
| Quote: |
I am using a PICDEM 2 Board from Microchip, and a 9V power supply.
It seems to work well, until I cycle the power supply on and off. The
hardware serial power stops functioning.
|
Enable the BROWNOUT fuse and add the ERRORS parameter to your
#use rs232() statement. Example:
| Code: |
#fuses BROWNOUT
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7, ERRORS)
|
|
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Sun Jan 31, 2010 10:17 pm |
|
|
| I tried the BROWNOUT option and the ERRORS option. I did a little more research, seems when I power-cycle I noticed that my serial power is outputting a lot of gibberish - not anything recognizable like it should be. Seems the timer0 still runs as well. I have also tried to set the brownout voltage level, no effect. I think the HWUART 'malfunctions' when it's powered back up - it's clear to me that the BROWNOUT fuse doesn't seem to be doing anything as far as reinitializing the code. Pushing the 'reset' button on the development board temporarily solves the problem until the next power interruption. Additional thoughts would be appreciated as I am at a loss on figuring this one out. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Sun Jan 31, 2010 11:01 pm |
|
|
| Quote: | | I noticed that my serial power is outputting a lot of gibberish - |
What is "serial power" ? Do you mean the serial port ? If so, which
serial port ? The PIC, the GSM, or the PC ? |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Sun Jan 31, 2010 11:52 pm |
|
|
| maxrate wrote: | | I tried the BROWNOUT option and the ERRORS option. I did a little more research, seems when I power-cycle I noticed that my serial power is outputting a lot of gibberish - not anything recognizable like it should be. Seems the timer0 still runs as well. I have also tried to set the brownout voltage level, no effect. I think the HWUART 'malfunctions' when it's powered back up - it's clear to me that the BROWNOUT fuse doesn't seem to be doing anything as far as reinitializing the code. Pushing the 'reset' button on the development board temporarily solves the problem until the next power interruption. Additional thoughts would be appreciated as I am at a loss on figuring this one out. |
Try this - physically disconnect the serial port then cycle the power supply - you may find it then works as expected. It could be that, although you have power cycled the board, the boards is being powered via the serial interface.
Enable the PUT fuse if the PIC has this.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Tue Feb 02, 2010 7:21 pm |
|
|
asmallri: good suggestion, that doesn't seem to be the issue.
PCM programmer: My apologies, I meant 'serial port'.
The hardware serial port is connected to the GSM modem. I have been probing the TX/RX pins - here is something strange: The port is set in programming to 9600 baud. When I power-cycle the project, that is when I get gibberish. I spent some time and determined that the PIC stops sending at 9600 and reduces it's speed to 2400 baud. If I probe the TX line using a terminal (setting the terminal to 2400) the text reads clear (after the power cycle) when I adjust the baud rate on my terminal (not desired operation obviously) - very, very odd as I have not specified 2400 baud anywhere in the code. I still do not know what to do about this problem. Very odd to me.
I am perplexed. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Tue Feb 02, 2010 8:34 pm |
|
|
| Quote: |
I determined that the PIC stops sending at 9600 and reduces it's speed
to 2400 baud.
|
1. Post your #fuses and #use delay() statements.
2. What is the Vdd voltage for the PIC ?
3. What is the crystal or oscillator frequency ?
Which one are you using - crystal or oscillator ?
4. Post your compiler version.
5. If you have a setup_oscillator() statement in your code, post it.
Ideally, post a very small test program that shows the problem.
You should be able to do that with just a few lines of code. |
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Fri Feb 05, 2010 2:40 pm |
|
|
I am using a external oscillator at 4.000Mhz - 5VDC PS, CCS 4.053 - I will work on example code.
Seems asmallri was partially correct after all (thanks asmallri). I haven't fully debugged the issue, however, there is some power 'leakage' from the serial device back into my project via the MAX233 chip. When I leave a DMM connected to the 5V power bus and remove power to the project the voltage level takes a long time to drop. When the serial device is left connected the DMM shows 0.64 volts on the 5V bus. When I disconnect the serial device the power eventually drops to 0V
If I power the device up anywhere below ~0.35 volts, it will come up properly. If the power level is above ~0.35 to 5 volts (when powered up) I get all the 'gibberish'. In all cases if I hit the reset button, the problem is cleared.
I am using a Microchip PIC DEM 2 PLUS development board.
I have 'played' around with brownout and Power Up Timer, etc - no improvement. The only major improvement I was able to make was removing a very large uF capacitor I had connected (when power removed, voltage level drops much quicker now).
I guess I'm looking for two things, a method in the software(firmware) that can reset at the appropriate voltage drop for the PICDEM2Plus board, and a method of isolating the RS232 port from 'stealing' power from the serial modem connected. (When the serial device is connected it keeps about 0.64 volts on the 5V bus.
When I originally took 'asmallri' suggestion on removing the serial device, I did so - but I still had that 3500uF cap connected!
Any suggestions at the moment short of posting code/etc - I'm close to releasing a 'test/example' source for anyone that can help. (I've stripped most of the program away completely)
Many thanks again to anyone reading this. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Fri Feb 05, 2010 6:53 pm |
|
|
| maxrate wrote: | I am using a external oscillator at 4.000Mhz - 5VDC PS, CCS 4.053 - I will work on example code.
Seems asmallri was partially correct after all (thanks asmallri). I haven't fully debugged the issue, however, there is some power 'leakage' from the serial device back into my project via the MAX233 chip. When I leave a DMM connected to the 5V power bus and remove power to the project the voltage level takes a long time to drop. When the serial device is left connected the DMM shows 0.64 volts on the 5V bus. When I disconnect the serial device the power eventually drops to 0V
If I power the device up anywhere below ~0.35 volts, it will come up properly. If the power level is above ~0.35 to 5 volts (when powered up) I get all the 'gibberish'. In all cases if I hit the reset button, the problem is cleared.
I am using a Microchip PIC DEM 2 PLUS development board.
I have 'played' around with brownout and Power Up Timer, etc - no improvement. The only major improvement I was able to make was removing a very large uF capacitor I had connected (when power removed, voltage level drops much quicker now).
I guess I'm looking for two things, a method in the software(firmware) that can reset at the appropriate voltage drop for the PICDEM2Plus board, and a method of isolating the RS232 port from 'stealing' power from the serial modem connected. (When the serial device is connected it keeps about 0.64 volts on the 5V bus.
When I originally took 'asmallri' suggestion on removing the serial device, I did so - but I still had that 3500uF cap connected!
Any suggestions at the moment short of posting code/etc - I'm close to releasing a 'test/example' source for anyone that can help. (I've stripped most of the program away completely)
Many thanks again to anyone reading this. |
The large capacitor will have negated the PUT (Power Up Timer). If you do need to use a large capacitor then I suggest you set the BOR at around 4.7 volts and enable the PUT.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Fri Feb 05, 2010 7:03 pm |
|
|
VDD: 5V
PIC: 18F4520
Development Board: Microchip PIC DEM 2 PLUS
External MAX233CPP RS-232 level (feeding from 5V power bus) - external GSM modem attached to TX/RX/CTS - 12V PS for GSM modem - both supplies grounds are tied together(also tied uncoupling)
4Mhz Oscillator
CCS: 4.104 (latest)
Digital MultiMeter attached to POST 5V voltage regulator. When powered up below 0.3volts (no problem), IF ABOVE .3 volts (capacitance) and the power is applied, gibberish RS-232 characters/project runs slower.
<MAIN.H>
| Code: |
#include <18F4520.h>
#device ICD=TRUE
//#device adc=8
#FUSES NOWDT //No Watch Dog Timer
//#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
#FUSES XT //Crystal osc <= 4mhz
#FUSES NOPROTECT //Code not protected from reading
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV27 //Brownout reset at 4.5V
#FUSES PUT //Power Up Timer
#FUSES NOCPD //No EE protection
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES DEBUG //Debug mode for use with 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 IESO //Internal External Switch Over mode enabled
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES NOPBADEN //PORTB pins are configured as digital I/O on RESET
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
#FUSES NOCPB //No Boot Block code protection
#FUSES NOLPT1OSC //Timer1 configured for higher power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES XINST //Extended set extension and Indexed Addressing mode enabled
#use delay(clock=4000000,RESTART_WDT)
#use rs232(stream=gsm,baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,ERRORS)
int timercounter = 0; // timer counter
|
<main.C>
| Code: |
#include "main.h"
#include <ctype.h>
#include <stdlib.h>
#priority INT_RDA, INT_TIMER0
void send_init_message() {
fputc('A',gsm);
fputc('T',gsm);
fputc('+',gsm);
fputc('C',gsm);
fputc('R',gsm);
fputc('E',gsm);
fputc('G',gsm);
fputc('=',gsm);
fputc('1',gsm);
fputc(13,gsm);
}
void send_init_txtformat() {
fputc('A',gsm);
fputc('T',gsm);
fputc('+',gsm);
fputc('C',gsm);
fputc('N',gsm);
fputc('M',gsm);
fputc('I',gsm);
fputc('=',gsm);
fputc('2',gsm);
fputc(',',gsm);
fputc('2',gsm);
fputc(',',gsm);
fputc('0',gsm);
fputc(',',gsm);
fputc('0',gsm);
fputc(',',gsm);
fputc('0',gsm);
fputc(13,gsm);
}
#int_rda
void serial_isr() { //incoming serial interrupt
char c;
c=getc(gsm);
}
#int_TIMER0
void TIMER0_isr(void)
{
//int result;
timercounter++; // increment timercounter
if (timercounter==3) { // reset timercounter
timercounter=1;
}
if (timercounter==1) {
send_init_message();
}
if (timercounter==2) {
send_init_txtformat();
}
}
[b]MAIN.C[/b]
void main()
{
int loop; // user for loop control
loop=0; // initialize loop controller
setup_wdt(WDT_OFF);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_16);
delay_ms(100);
enable_interrupts(INT_RDA);
enable_interrupts(INT_TIMER0);
enable_interrupts(GLOBAL);
while(1) {
}
}
|
This is the remaining code from the program which I have stripped down. |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Fri Feb 05, 2010 7:45 pm |
|
|
| Quote: |
CCS: 4.104 (latest)
#FUSES LVP
#FUSES XINST
|
Did you put these lines in or did the Wizard do it ? I don't have the IDE
so I don't know. If it's the default state of the Wizard, this needs to
be reported to CCS.
Change those to NOLVP and NOXINST. Using LVP will cause the PIC to
lock-up if pin B5 goes high, and XINST will cause erratic operation of
the program. |
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Fri Feb 05, 2010 8:05 pm |
|
|
The wizard did it - I changed the fuses as per your recommendation and the same thing happens. My next step is to remove all external circuitry and use the PIC DEM 2 PLUS board on it's own (no external wires) - luckily I own two of these development boards, so it should be easy.
Thank you for your help so far
| PCM programmer wrote: | | Quote: |
CCS: 4.104 (latest)
#FUSES LVP
#FUSES XINST
|
Did you put these lines in or did the Wizard do it ? I don't have the IDE
so I don't know. If it's the default state of the Wizard, this needs to
be reported to CCS.
Change those to NOLVP and NOXINST. Using LVP will cause the PIC to
lock-up if pin B5 goes high, and XINST will cause erratic operation of
the program. |
|
|
|
maxrate
Joined: 01 Jan 2007
Posts: 38
Location: Mississauga, Ontario, Canada
|
|
| Posted: Fri Feb 05, 2010 8:24 pm |
|
|
OK - so, I've concluded that it is definitely external circuitry related. Using only the (other) PIC DEM 2 Plus board (no external circuitry), I can power cycle as much and seemingly as rapidly as I'd like and there seems to be no 'crash'. Sadly, the external circuitry is very simple. All I have is a MAX233CPP chip connecting to the GND and 5V, along with RX/TX going to the GSM modem. I am pulling the CTS (or DSR) pin (can't remember) high on the GSM modem using the 5V bus - I have removed that and I am using an external 9V battery to pull that signal high on the GSM modem (isolated from the circuit - other than GND)
At this point, I'm not quite sure where this leaves me. I mean, I would expect that a PIC controller have the capability of resetting itself and booting up properly in harsh conditions. Interestingly enough my final design will be using a 5V GSM modem with no RS232 level converter - but I'm still extremely keen on solving this mystery.
There are two parts to this: 1) the PIC not responding the way I would expect it to, and 2) how to stop the MAX233 chip from supplying 0.64Volts to the 5V bus when the PIC DEM 2 Plus board in unpowered otherwise.
I've been researching online - having trouble finding what I need to find. I'm not always the best at Googling I suppose.
I am glad we have at least isolated to some degree where the trouble is, but I am still determined to get to the very root of this issue. Not sure what my next step is at this point. |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Fri Feb 05, 2010 9:43 pm |
|
|
| maxrate wrote: |
#FUSES BORV27 //Brownout reset at 4.5V |
Your BOR is wrong - the fuse value does not match the comment. This will definitely result in the symptoms you are seeing.
_________________
Regards, Andrew
http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!! |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Feb 06, 2010 4:43 am |
|
|
I'd suggest that the problem is probably that the PIC is resetting, but the modem is not.
If the modem has not reset, what mode may it be in?. Is there a software sequence you can send it to put it into it's 'reset' confdition?. Usually there is a command sequence you can send to reset the modem.
Typically it is something like:
Pause.
Line feed.
+++
Line feed.
Pause.
This depends on the device, but this was a typical one.
So, your 'wake up', should be something like:
Pause - make this long enough for the MAX chip to wake up, and the modem, if they have reset.
Send the software sequence to reset the modem.
I suspect the 0.64v, is not your problem, but that the modem is not in command mode, so ignores the sequence you are sending, and hence the code doesn't work.
Does the modem have an external reset line?. If so, then consider operating this with the PIC, and putting the modem into 'reset' condition this way.
Best Wishes |
|
|
|
|
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
