 |
 |
| View previous topic :: View next topic |
| Author |
Message |
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| debugging under #fuses INTRC? |
 Posted: Mon Mar 23, 2009 5:16 am |
 |
|
Greeting:
Is debugging code written using #fuses INTRC possible? When I try to debug my application written using this configuration, my ICD-U40 reports loading the code, but in due course reports: “Could not start target: The target was not halted after reset…”
To demonstrate this issue, I have prepared the following simple test program. In anticipation of the actual hardware, I am developing on an older platform that has an external oscillator (the ultimate hardware will run on only the internal RC). Consequently, the test code is written such that either HS or INTRC fuses may be pound-defined in, so I can switch between modes with no other changes. Here’s the code:
| Code: |
//* choose either high speed or internal oscillator... ******************
#define USE_INTRC
//#define USE_HS
//***********************************************************
#include <18F24K20.h>
#byte PORTC = 0xF82
//* setup from wizard ******************************************
#device ICD=TRUE
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#if (defined USE_HS )
#fuses HS
#elif ( defined USE_INTRC )
#fuses INTRC
#endif //elif ( defined USE_INTRC )
#if (defined USE_HS)
#use delay(clock=11059200)
#elif (defined USE_INTRC)
#use delay(clock=16000000)
#endif //elif (defined USE_INTRC)
//***********************************************************
void main()
{
disable_interrupts(GLOBAL);
//* manual PIC setups ********************************
set_tris_a ( 0xFF );
set_tris_b ( 0xFF );
set_tris_c ( 0xBF ); //set PORTC6 output for toggling a bit
//* test loop *****************************************
while ( TRUE )
{
bit_set ( PORTC, 6 );
delay_ms ( 10 );
bit_clear ( PORTC, 6 );
delay_ms ( 10 );
}
}
//***********************************************************
|
When compiled for HS, this code debugs without problem.
When compiled for INTRC, however, the debugger reports the “Could not start target…” error.
I have compiled the test for both modes and, via CCSLOAD, loaded the hex output to the target PIC18F24K20 via my ICD-U40. Both run (the version compiled for the INTRC fuse runs its delay_ms(10) slightly but measurably slower than under HS fuse).
Is there anything obviously wrong here? I’ve noticed in the debug window there is a “Use External Oscillator” option. It seems reasonable that code written for INTRC would require this to be changed to FALSE, but doing so has no effect. The debugger still reports “Could not start target…” when invoked.
Thanks for any advice.
Doug |
|
 |
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| debugging under INTRC - continued |
| Posted: Mon Mar 23, 2009 8:13 am |
|
|
For what it is worth, I find I can modifiy the above code as follows:
| Code: |
void main()
{
disable_interrupts(GLOBAL);
#if (defined (USE_HS))
OSCCON = 0x77;
OSCTUNE = 0x40;
#endif //(defined (USE_HS))
.
.
.
|
With this addition, start the test program with #fuses HS enabled, then switch to the internal oscillator on the fly. This works, of course, on the platform I am using right now (with the external oscillator), but will do me no good dealing with the actual target hardware (arrival due at any moment, by the way).
I would also amend my first note to specify I am using the compiler version 4.088 and an ICD-U40 version 101.
Thanks,
Doug |
|
|
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| more on debugging #fuses INTRC |
| Posted: Tue Mar 24, 2009 4:57 am |
|
|
Quoted here is the complete text of the error message reported when trying to debug the above code compiled with the #fuses INTRC:
| Quote: |
Could not start target: The target was not haulted after
reset. Check the target oscillator and MCLR.Make sure the
target clock match the clock fuse and that the target is
oscillating.Use View | Valid fuses to find the correct clock
fuse.
|
It is impossible to know if this is just a generic error message, or if the ICD-U40 actually requires an external target clock buzzing in order to start up.
Has anyone succeeded in debugging systems running under internal RC? |
|
|
dpaul
Joined: 15 Mar 2005
Posts: 12
|
| INTRC Resolved (maybe) |
| Posted: Tue Mar 24, 2009 2:55 pm |
|
|
I may have solved this issue.
I last updated my ICD-U40 firmware I believe last Friday, when the version number was bumped to 2.51.
I just became aware the current version is 2.53. I downloaded this into the ICD-U40 and I can now debug!
I am, of course, very much pleased. The debugger reports 1MHz operation, even though I am setting OSCCON to 0x7C (that is, 16MHz HFINTOSC direct drive). That may or may not be a problem (I will have to wire a test pin to toggle to verify the actual clock). |
|
|
JayTalbott
Joined: 01 Apr 2009
Posts: 3
Location: Gilbert, AZ
|
| Re: INTRC Resolved (maybe) |
| Posted: Wed Apr 01, 2009 12:40 pm |
|
|
| dpaul wrote: | | I just became aware the current version is 2.53. I downloaded this into the ICD-U40 and I can now debug! |
How did you get 2.53? The ICD utility on my system says 2.51 is the latest version. I can't debug with 2.51, so I'm hoping that 2.53 will fix things.
- Jay |
|
|
JayTalbott
Joined: 01 Apr 2009
Posts: 3
Location: Gilbert, AZ
|
| Still can't debug |
| Posted: Wed Apr 01, 2009 4:26 pm |
|
|
The ICD utility only seems to know about 2.51, but ccsload knows about 2.53, so I was able to update the firmware to 2.53 using ccsload.
However, I still can't get debugging to work...
The board uses a PIC18F4680. I've done all the diagnostics, and the signals to all the programming/debugging pins from the ICD-U40 appear to all be correct.
Yet, I still get the "Could not start target" error message when I try to use the debugger. If I build the code w/o debugger support, I can program and run code just fine (other than the quirkiness of the CCS tools not being able to connect to the ICD half the time). I just can't debug.
Here's my fuses configuration:
| Quote: | #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 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 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=40000000,osc=10000000)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8)
|
I've also tried HS instead of H4 with clock=10000000 so that the PIC runs at 10 MHz instead of 40, but it didn't help.
I've searched and read this forum looking for answers, but so far I've come up dry.
Anybody have any suggestions?
- Jay |
|
|
|
|
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
