JayTalbott
Joined: 01 Apr 2009
Posts: 3
Location: Gilbert, AZ
|
| Can't debug (amoungst other issues)... |
 Posted: Fri Apr 03, 2009 5:31 pm |
 |
|
I'm trying to program and debug code for the PIC18F4680, using an ICD-U40.
I have upgraded to the latest compiler (v. 4.090), and the latest ICD-U40 firmware (v. 2.53).
I can program the chip fine, and if I don't specify #device ICD=TRUE or #FUSES DEBUG but instead specify #FUSES NODEBUG, I can build code and get it to run fine, other than the headaches with connecting to the ICD-U40 (which I'll get into later).
However, if I do specify #device ICD=TRUE or #FUSES DEBUG, then I can still build the code and program the chip, but I can't run or debug the code. Instead, I get the dreaded "Could not start target" error.
I've done all the diagnostics, and the signals to all the programming/debugging pins from the ICD-U40 appear to all be correct, so it does not appear to be a connection issue. Also, since I can program the chip, that also suggests it's not a connection issue. Pins RB3, RB6, and RB7 are not shared, but are only connected to the programming/debugging port on the board.
I've searched and read this forum looking for answers, but so far I've come up dry. Others have run into similar problems, but fixed them by changing certain fuses or upgrading to the latest compiler or ICD firmware. However, I've tried all those things, and I still get the same result.
Here's my configuration:
| Code: | #include <18F4680.h>
#device ICD=TRUE
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES WDT128 //Watch Dog Timer uses 1:128 Postscale
//#FUSES HS //High speed Osc (> 4mhz for PCM/PCH) (>10mhz for PCD)
#FUSES H4
#FUSES NOPROTECT //Code not protected from reading
#FUSES NOBROWNOUT //No brownout reset
#FUSES BORV21 //Brownout reset at 2.1V
#FUSES NOPUT //No 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 NODEBUG //No Debug mode for ICD
#FUSES NOLVP //No low voltage prgming, B3(PIC16) or B5(PIC18) used for I/O
#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 BBSIZ4K //4K words Boot Block size
#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 LPT1OSC //Timer1 configured for low-power operation
#FUSES MCLR //Master Clear pin enabled
#FUSES NOXINST //Extended set extension and Indexed Addressing mode disabled (Legacy mode)
//#use delay(clock=10000000)
#use delay(clock=40000000,osc=10000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8) |
I've tried HS instead of H4 (and changing the #use delay line accordingly), but that didn't make any difference.
Some have suggested that the order of the fuses can make a difference, but that seems awfully black art to me (if it does make a difference, that's a real crappy design of the development tools). I will say that I did, after programming the part, check the fuse configuration with ccsload, and it matches the fuse settings. So at least they are getting programmed correctly.
Is there something I'm missing? Does anybody have any suggestions for how to fix things so that I can debug my code?
Also, about every 4th or 5th time I try to connect to the ICD-U40, either when programming the chip via PCW, or when firing up either the ICD utility or ccsload, I'll get "Device Programmer Connection Dialog #100", asking "How is your device programmer connected to the PC". It comes up with "USB port" already selected, so I just click OK.
After that, sometimes I'll get "Device Programmer Connection Dialog #122", stating that it "Can not connect to USB device programmer", because "Another program is already connected to the device programmer", even when no other program is using the ICD-U40 at the time. In this situation (happens a lot with ccsload), and retrying doesn't help.
Or, sometimes after the first dialog I'll get "Device Programmer Connection Dialog #140", asking me to unplug the ICD-U40, followed by "Device Programmer Dialog #141", asking me to plug it back in (happens a lot either when programming from within PCW, or when launching the ICD utility). About half the time, that works, and it then connects. Other times it then pops up "Device Programmer Connection Dialog #145", where it's attempting to identify the device. Sometimes if I click OK it works, sometimes it doesn't. If it doesn't, I ultimately have to uninstall the driver for the ICD-U40, then unplug the USB cable and plug it back in again, and go through the "found new hardware" wizard in Windows.
Am I alone with this issue, or does this happen to everyone? Does anybody have any suggestions of how to fix this? It's sure a PITA when iteratively re-building and re-programming the code during development.
Thanks,
- Jay |
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
