View previous topic :: View next topic |
Author |
Message |
mbevacqua
Joined: 11 Apr 2011 Posts: 5
|
Serial Data Incorrect without ICD |
Posted: Mon Apr 11, 2011 5:58 pm |
|
|
I'm having an issue which is strange enough that I may just be missing something simple.
I've got a program on my 18F4520 which uses the #1 serial port. The application works perfectly as long as the ICD is connected and been used. It doesn't have to be debugging, just loading a programing will do. However when I disconnect the ICD and reset, the program runs, but the data out of the serial port is not right (I get something at the right times, but I'm not sure what.) Before I hook up an oscilloscope to figure out exactly what "not right" means (bad baud rate, parity etc..) does anyone have a suggestion for something I may be missing here?
Thanks. |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Apr 11, 2011 6:22 pm |
|
|
Is the serial cable connected to your PC ? Did you buy the cable, or
did you make it yourself ? Is there a ground wire in the cable ? In the
DB-9 on the PC, pin 5 is the ground pin. There must be a ground
connection between the PC and the PIC board (in addition to the Rx and
Tx signals). |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Mon Apr 11, 2011 6:33 pm |
|
|
Do you have a MAX232 or equal chip installed ? I 'assume' since you're not using the ICD, you've bypassed the one inside it ? |
|
![](templates/subSilver/images/spacer.gif) |
mbevacqua
Joined: 11 Apr 2011 Posts: 5
|
|
Posted: Mon Apr 11, 2011 6:40 pm |
|
|
Thanks for the response, two bits of info. This first is new:
The serial lines are being sent through an FTDI serial to usb chip. The ground and signal lines between the PIC and FTDI haven't changed because they are all on the PCB.
Second, just plugging the ICD in doesn't help. You have to actually do something with it, like load the program (or maybe only load the program I think starting CCSLoad and the Debugger bother do that automatically when started.)
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
mbevacqua
Joined: 11 Apr 2011 Posts: 5
|
|
Posted: Mon Apr 11, 2011 6:45 pm |
|
|
So you don't have to assume: I'm using RB6&RB7 for the ICD and RC6andRC7 for the serial.
Another thing I've noticed is that I seem to be getting "firmware" out of date errors occasionally when I start CCSLoad after a reboot.
This is the first time I've used a PIC so I'm not sure what's normal procedure and whats not.
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon Apr 11, 2011 11:30 pm |
|
|
1. Post your #fuses settings.
2. When you try to run the board without the ICD attached, are you
compiling the program in "Release" mode or in "Debug" mode ?
Try doing it in Release mode. |
|
![](templates/subSilver/images/spacer.gif) |
mbevacqua
Joined: 11 Apr 2011 Posts: 5
|
|
Posted: Mon Apr 11, 2011 11:56 pm |
|
|
Here are the fuses:
#FUSES WDT8 //Watch Dog Timer uses 1:8 Postscale
#FUSES EC //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES FCMEN //Fail-safe clock monitor enabled
#FUSES IESO //Internal External Switch Over mode enabled
#FUSES NOPUT //No Power Up Timer
#FUSES BROWNOUT_SW //Brownout controlled by configuration bit in special file register
#FUSES BORV20 //Brownout reset at 2.0V
#FUSES PBADEN //PORTB pins are configured as analog input channels on RESET
#FUSES LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES STVREN //Stack full/underflow will cause reset
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
#FUSES DEBUG //Debug mode for use with ICD
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOCPB //No Boot Block code protection
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#FUSES NOWRTC //configuration not registers write protected
#FUSES NOWRTB //Boot block not write protected
#FUSES NOWRTD //Data EEPROM not write protected
#FUSES NOEBTR //Memory not protected from table reads
#FUSES NOEBTRB //Boot block not protected from table reads
When you say release mode, is that just changing the fuse to NODEBUG? I'm having some issue setting the fuses, maybe this is where I'm going wrong. If I change the fuses in the header file, clean, rebuild and load the project, when I open CCSLoad the fuses still show as above, the changes don't stick. If I change the fuses in CCSLoad, save as a new hex file and reload, I get a load verification error.
Thanks |
|
![](templates/subSilver/images/spacer.gif) |
Ttelmah
Joined: 11 Mar 2010 Posts: 19366
|
|
Posted: Tue Apr 12, 2011 2:17 am |
|
|
Several slightly different answers, depending on your working environment.
1) If working in MPLAB, recent releases of this _default_ to using 'DEBUG' mode, and override the CCS fuse settings. Build option, select 'release'. Microchip are meant to be changing the default to 'release' in the near future.
2) In CCS, the 'DEBUG' fuse. Also #device ICD=TRUE. Both need to be removed if present. NODEBUG, is the default if neither of these is present.
Best Wishes |
|
![](templates/subSilver/images/spacer.gif) |
temtronic
Joined: 01 Jul 2010 Posts: 9173 Location: Greensville,Ontario
|
|
Posted: Tue Apr 12, 2011 5:14 am |
|
|
Also you'll have to recompile ( F10 ) AFTER you change the build configuration to 'release', then burn the PIC ! |
|
![](templates/subSilver/images/spacer.gif) |
Douglas Kennedy
Joined: 07 Sep 2003 Posts: 755 Location: Florida
|
|
Posted: Tue Apr 12, 2011 7:23 am |
|
|
ICD controls MCLR ( the programmer will pull it up whether you independently do or not have a pull up). It is expected that you are responsible for pulling up MCLR when the ICD is disconnected. |
|
![](templates/subSilver/images/spacer.gif) |
mbevacqua
Joined: 11 Apr 2011 Posts: 5
|
|
Posted: Tue Apr 12, 2011 9:36 am |
|
|
Thanks everyone. The problem was:
#device ICD=TRUE
I suppose a little more initial manual reading would have turned that up as well. I find it odd that it was only effecting the serial transmission. |
|
![](templates/subSilver/images/spacer.gif) |
|