Can't debug PIC24 Project

[soonc]

I've been working my a PIC24FJ128GA306 project for some time, and appreciate all the help I've received during that time.

Compiler V5.062

For several weeks now I've been adding code and really not had the need to use the debugger.

Yesterday I did. I enabled the code for debugging, and using the PCWHD the code loads and executes.

Then I set a break point which was ignored. ! The LST file shows valid code for the location.

I called CCS tech support and they were not able to help but would look into the problem.

When I start the code with NO break points, and then Stop the debugger the Program Counter is always at 0001 ! If I click Step the PC goes to FFFFF

If I set a break point (it is ignored) and then Stop the debugger the Program Counter is also always at 0001 ! If I click Step the PC goes to FFFFF

Has anyone had a similar program and if so is there a known solution ?

Otherwise the code works as expected.
Currently I'm debugging using printf() statements to the display but that's such a time consuming way to debug.

[Ttelmah]

There was a problem a while ago, with another chip in this family, with the wrong 'debug executive' code being loaded. You do understand that with the ICD, a separate small program is loaded into the chip near the top, which is what handles intercepting the operations to allow debugging.
Now, things that could cause problems:
Do you have a slightly older compiler you can try?. In case there is an executive problem with .062.
Having code that writes to the area occupied by the ICD code. It should warn you about this, but again I have seen 'oddities' here.
Have you checked that the firmware in your debugger is up to date?. Have seen problems when a new compiler updated the executive, but the ICD firmware was an older version. Run the ICD up in CCSLoad, and under the diagnostics tab, check that the software and firmware are both the current version.
Are you sure the debugger is connecting to the right unit?. I have both a Mach-X, and an ICD, and it sometimes has the habit of deciding to start talking to the wrong unit if both are attached.
Other classic thing that can cause a huge range of problems, is having a slightly too long ICD cable. Especially on the faster chips, the length does become very important.

[soonc]

Last to first:
A)Yes: I have short cable from ICD to target.
A)Yes: I only use 1 ICD at a time.
A)Yes Firmware is Up to Date. ICD-U64 V3.17
A)I do not have Special code.
A)I tried V5.057 same problem.

CCS Tech. Support mentioned something about the debugger code and I think that's is what they are looking into.

In the meantime I managed to get past this issue using the printf() debugging method.

Code is just about done. Lot's of testing to do. Each test can take up to 15 minutes to complete due to sensor data availability and not code speed!

Thanks for the insight to the 'debug exe'.

[Ttelmah]

I know what you mean about debugging. Have a bit of kit at the moment, takes about a minute to make a code change, but you then have to wait for the GSM to connect, the time to synchronise, the data to start logging etc. etc.. Watching paint dry is positively interesting comparatively....

Does sound as if there may be a bug in the executive code on this chip.

[soonc]

I forgot to mention.
Loading a small test project and the debugger runs as expected. !

This weekend I'll try to go back to a much earlier (smaller) version and see if that debugs ok...

thanks again

[Ttelmah]

Just a suggestion,
Try increasing your stack size.

The debugger uses some stack space. If you are running low, it could stop it from working.

[soonc]

Stack was 1024 I tried 2048 and it did not cure the problem.

I did try something else:
Reset and the Run to Cursor.
The debugger does not stop.

If I then click Stop it produces new error message:-

"Could not run the target: The Target was not halted. "
PC=0001 ... Ready MCU at 0.02MHz

Next I set a break point at that same line, and reset the debugger and then Clicked Run, and the debugger does not stop.

If I then Click Stop there is NO error message.

PC=0001 ... Ready MCU at 0.02MHz

Why the clock stops may be a clue.

Then I loaded the very small test program:

Run to cursor Stops as expected and PC=023E ... Ready MCU at 7.37MHz
The clock does not stop !

I'm not sure what this all means but I'll pass the info on to Tech. Support in the hope that it gives them a clue as to the source of the problem.

[temtronic]

this...
PC=0001 ... Ready MCU at 0.02MHz

says the chip is running at 20KHz.

Now I don't use that PIC but even so, that's really,really slow as if a 'backup' clock was running NOT the regular one. Or the RC clock without a cap ?

Perhaps the PCB isn't soldered correctly, xtal is bad, wrong caps, PSU failure,??

I never use 'debug'(I'm 'old school', test in the real World...) but if 'debug' works with a small program and the ONLY changes are code size, maybe a 'boundary' is being violated. Are the 'fuses' ALL the same between 'big and 'small' programs ?

Since small works, increase the the code size until it fails and report the code size..

Jay

[Ttelmah]

Are you clock switching?.

There is an issue with several of these PIC's, where they won't actually allow you to switch between different frequencies involving the PLL. Doing so, can stop/partially stall the oscillator.
If you are switching, you do this without problems by switching to the INT_RC source, then selecting the new frequency, and changing back.

I've found the frequency measure on the ICD is often significantly wrong, so it is possible you are actually running at 31.25K.

[soonc]

Thanks for input.

I have the Clock Switching fuse set, but this version so far does not do the clock switching. I am really hoping I can keep total current draw low enough to not have to do that.

uP on board RTC clock uses an external MAXIM 32KHz which runs constantly while there is power to the uP. Maybe that's what the debugger is sniffing when I do a break.

PCB are high quality, automated assembly with Pick n Placed components etc.

Code size was my main concern.
Going backwards and reducing code size until it works may be an option but will take a LONG time to do.
The time may better be used to do the printf() debugging method. At least the design has a display !

Fuses are the same between small test program and large code.

I'll plod along with printf() debugging... and see what tech. support comes up with next week.

[temtronic]

I've always dedicated one pin for printing to a PC for 'debug' purposes.when using RS232 (MAX232) chips... 1/2 was wired for 'PC' use. These days I just wire in a TTL<>USB module.
PIC have LOTS of pins, so really it costs 'nothing' to have a solid hardware connection!

Jay

[Ttelmah]

Look at your connections, and what peripherals are programmed differently.

The two debugger pins (and the MCLR) are quite sensitive to resistances and capacitances. How have you got them wired?. One obvious thought would be something like a solder bridge to one of the debugger pins from an adjacent track, that is programmed to a level in the 'full' code, and is left floating in the small test program. Result the debugger hiccups...

[soonc]

Well this design is using all pins, but it also has all four UARTs in use.
The small graphics display has been useful, but it takes time to write/update the display.
In this part of the code the GPS is not being used so I think I'll wire it to my PC with a Level shifter.

Possible Solder bridge:
The reason I'm not searching for other hardware issues are because the code grew on this set of hardware, and it did work with the debugger a few weeks ago.
Nothing has been done to the PCB these are assembled for me.
I have a handful more of the same initial production so I could try moving to another board.

Thanks for all the helpful suggestions.

[soonc]

I've started using a hard wired serial port connection to debug this project.

I don't do this very often and once I started I realized why !

Using a simple terminal program to display the data for about 10-12 variables in real time is a mess.

Putting Variable names on a line and watching them change works but there is little value to that kind of display as any debugging comments flash by and they are gone.

Logging to a file is an option, but tedious, and is not realtime or even close.

I studied Various Terminal standards and Formatting to control the terminal cursor position this is also very tedious and eats a lot of PIC programming space.

I looked for a PC program to display simple streaming serial data and control where the data is displayed, so that watching one particular variable relative to other variables is all within on stable screen.

I could not find anything, most likely because I did not know/use the proper keyword for my search. I can't believe such a program does not exist.

I'm thinking of writing my own unless someone can point me to a site where such a program can be downloaded.

[temtronic]

I don't know of any 'PC terminal data display' program that is configurable, like you need. In the early days I used QB45 to display PIC data as it used real interrupt driven comports. Once the hardware comports were dropped for USB and Windows got messy, I used 'Delphi' for custom 'terminal display'. The great thing about Delphi is that it creates SMALL stand alone programs and will work on any PC with any version of windows.
Others who make a living off this will be up to date about what may work for you, though Delphi only took me a week to learn enough to cut useable code !

Jay