PIC18F45K50 is not ready for debugging

stoyanoff · Joined: 20 Jul 2011 Posts: 375

Greetings! I'm using PIC18F45K50, MPlab v8.91, CCS v 5.024.
These are my fuses:

temtronic · Posted: Mon Feb 22, 2016 6:28 am

comments..
1) there's more than 4 fuses in that PIC, so one of the 20+ others could be the culprit.

2) pretty sure you cannot have the WDT enabled when in debug, I never use debug but see that comment here every so often.

3) MPLAB has it's own ideas about 'debug' mode vs. 'release'. My MPLAB defaults to 'release' mode as I don't debug using 'debug'.

Jay

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

what does your CIRCUIT look like?
pullups or pulldowns on debug pin?

is everything a-ok in that department ?

stoyanoff · Joined: 20 Jul 2011 Posts: 375

DEBUG pin?! I'm using standard ICSP connections. There are no resistors on PGD and PGC!
Do I have to do anything special for this controller?!
I'm using it for a very first time. I have experience with PIC18F25K50 - the series. I had no problems with it!
Thanks!

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

ICPRT = 1 ??

PIN_B6 / B7 TRIS ok?

not knowing what package --
ICCK I/O ST Dedicated In-Circuit Debugger clock. ok?
ICDT I/O ST Dedicated In-Circuit Debugger data. ok?

and

CONFIG4L DEBUG XINST ICPRT — — LVP — STRVEN 392
set ok? in .LST tail ??

stoyanoff · Joined: 20 Jul 2011 Posts: 375

PIC18F45K50-I/PT
I have connected only the ICSP pins.
ICCK and ICDT and ICRTS are not connected
Do you mean there are different pins for debug then program?!
Thanks!

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

stoyanoff · Joined: 20 Jul 2011 Posts: 375

I'm sorry! 44-PIN TQFP!

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

and using pins 12,13,18,33 right ??

its different SHARED pins on the 40 pin dip

stoyanoff · Joined: 20 Jul 2011 Posts: 375

I've fixed it! It seems I had to check "compile for use with ICD Debugger"!
Thanks!

Ttelmah · Joined: 11 Mar 2010 Posts: 19551

This implies you have changed this setting sometime in the past.....

When using MPLAB, it always overrides the settings for DEBUG 'for you'.
By default MPLAB always sets the processor to debug mode (which is why there are regular threads here with people having problems not being able to program a chip for normal use).
At some point in the past, you have set it to compile for 'release'....

asmboy · Joined: 20 Nov 2007 Posts: 2128 Location: albany ny

As someone whose practice has more than the average of time critical routines - i have NEVER found any potential benefit from using MPLAB and the Debugger.

Seems more trouble than any possible benefit.

IMHO there are better ways to figure out some malf'ing code,
and i've long used a combo of scope attachment to an un-comitted I/O pin , and odd bits of situational based extra serial output data.

My personal opinion is that the best debugger is between your ears and
that when debug is needed - it better to improvise based on the situation at hand.
The PIC does not run in a vacuum.

I'd love to hear from anybody who makes regular good use of MATLAB/DEBUG and especially the WHY of working with it.

temtronic · Posted: Tue Feb 23, 2016 10:42 am

hmm...

RF_Developer · Joined: 07 Feb 2011 Posts: 839

I do a lot of debugging... but I never use MPLAB and never use simulators. I find it clanky and clumsy and a poor environment to work with CCS C. I always use the CCS IDE and the integrated debugger. On the other hand, MPLAB and ICD3 is one of our historically preferred production programming environments (we now use the CCS Load-N-Go far more often, using the ICD3 for legacy code and for one-off specials).

I also use debug pins a lot, trying to keep one or two at the corners of PICs just for that purpose. The systems I tend to work on are usually just that, systems, with multiple PICs working together and intercommunicating. The amplifier I have running beside me has 12 PICs in all, all bar one connected via a system-wide CAN bus, which also goes via a CAN adapter box to the PC where I have a C# GUI that we use for system monitoring and diagnostics. In such systems, I will live debug one PIC at a time, hoping and praying that the others all behave for me. Some systems require debugging on two or more targets simultaneously, and that creates some real headaches. :-(( But I do it all from the CCS IDE.

newguy · Joined: 24 Jun 2004 Posts: 1909

As I mentioned a while ago, all my projects have two debug LEDs, and that's how I debug pretty much everything. I create industrial systems that lack any kind of human interface at all and communicate with other boards/systems via serial or CAN busses. Rarely I'll "sniff" the serial communications or CAN bus, but usually only when I'm at the limit of what the 2 LEDs can tell me. Given the nature of the systems I'm working on, it's not possible to run a traditional debug kind of environment because I need what I'm debugging to be up & continuously running in order to determine what it's doing or not doing.

The only times I've had difficulty debugging is when the fault wasn't with a single project, but instead lay in the interaction between two projects. The worst one (one that took the longest to find) was with two boards that communicate via CAN on their own dedicated CAN bus (no other devices on the bus). Eventually the CAN link between them would go down - neither one could successfully transmit. Took me forever to realize it was because the two would attempt to take control of the CAN bus at almost precisely the same moment while attempting to transmit the same message. They'd eventually each decide that they'd lost arbitration, give up (as they're supposed to do), then retry (again, as they're supposed to do, but they were resting the same amount of time), only to again realize "someone else is speaking" and again give up. Ad infinitum. Once I realized the true cause, I was able to easily fix it. ....But that one took a while.