Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

mplabx wont debug

Status
Not open for further replies.
20160827_190539.jpg
 
I think i found it, in the data sheet:

In-Circuit Debugger
- MPLAB ICD 2

.....that means no debug with pickit 3 doesnt it?
 
I still use MPLAB 8... The "Device" selection window has always been the most informative in this regard..

I have debugged an 18f4520 ( just less memory ) with pickit 2.... The limitations are usually the software breakpoints.. But according to MPLAB the pickit3 will debug that chip!!
 
Hi doc As said , PK3 will debug your device, From your picture you have lined up PK3 data / clock pins to the IC pins presumably with a long pin header, does that include PK3 pin 6 connected to the pic pin ?. I have found problems arise if you put a signal on that pin(6) .. You don't need the large electro cap across the power you do need some .1uF on all the Vcc Vdd pins .also I see your PK3 is a clone ?
 
10 & 100 uf is all i had layin around, i can dig to be more accurate with the 0.1
I have removed pickit pin6 specifically (not like in photo)
both power rails hooked up now
not sure about if it is clone, but dont think so, it says on the front "mplab pickit3" with a "M" on it..
 
Hello there,

I dont use PicKit3 but when debugging code many compilers insert instructions sometimes after every little code line so it can stop anywhere if needed. In a Windows machine that's not usually a problem it just results in slower running code. But in a uC with limited resources i would think it might be more of a problem. If it sees that there is too much code it may not program the device, or it might just try and fail.
I dont know how much memory you have with that particular MC chip but it's at least worth a check.

You can also check to see what the behavior is when you add TOO MUCH code by adding lots more code. See if it tells you or just quits silently like this is doing.

If that's not it, then you can try to troubleshoot by removing less important code (rem it out) and see what it takes to actually get it to actually work in debug mode. That might tell you something or at least give you some sort of starting point. You can then add back the code little by little and see if you can detect what code caused it. Maybe debug is catching an error in some code.
 
I dont use PicKit3 but when debugging code many compilers insert instructions sometimes after every little code line so it can stop anywhere if needed.

Most of Microchip PICs have built-in hardware debugging capabilities, so the debugger doesn't need to mangle the code. It does insert a small program (500 bytes or so) called "debug executive". It is used to talk to the debugger while the chip is halted. Most chips (but not 4620) have special space for the debug executive which is not documented and not visible for a regular program.
 
Most of Microchip PICs have built-in hardware debugging capabilities, so the debugger doesn't need to mangle the code. It does insert a small program (500 bytes or so) called "debug executive". It is used to talk to the debugger while the chip is halted. Most chips (but not 4620) have special space for the debug executive which is not documented and not visible for a regular program.

Hi,

Ok great, but then how do we explain the increase in size from non debug to debug builds?
Less than 0x200 to more than 0xF000.
 
Ok great, but then how do we explain the increase in size from non debug to debug builds?
Less than 0x200 to more than 0xF000.

It is not really increase in size. It's his program at the beginning, debug executive at the end, and huge hiatus in the middle.
 
unfortunately, since i am reaching at straws, i am now using a basic blink code ..... but i feel we are getting warmer chasing these kind of problems.,

again i will contact microchip and let you(us) know what they say.....
 
It is not really increase in size. It's his program at the beginning, debug executive at the end, and huge hiatus in the middle.


Hi there,

Ha ha, i like the use of language there with the 'hiatus'.

Well if that is the case then we have to trust that whoever wrote the software knew enough to place it in the right place without overflowing the memory. I dont know how much mem that chip has, but 0xF000 is getting near 65535 bytes.

Doggy, try removing small portions of code and see if you can get it to work. Once you get it working, and you should since you said you got other code working, then you can back track and see what section of code does it. Once found, you can then try a different section of roughly the same size and see if that does it too. If the second set does not do it, then it could be some strange error in the code.

Let's not forget about the little Arduino bug where three !!! in a row would crash the compiler. Once removed, it worked fine.
That's because someone used that as a 'flag' to jump into another program mode, which of course made it impossible to upload sketches.
 
never heard of that!!! but have tried the most basic code available:

void main(void)
{
TRISBbits.TRISB0 = 0;
while(1)
{
LATBbits.LATB0 = 1;
LATBbits.LATB0 = 0;
}
}

but thanks!, every idea helps in these situations
 
Doc... Still think your PK3 is a clone , back of a PK3 has serial # , also tracks and components inside are different to your photo.
 
the PK3 serial number is reported in the MPLABX dashboard pane , or the project config ?
edit ( perhaps not a good idea to post # just that it has one )
 
Last edited:
I think this is what you are lookin for....also it does have serial number starting with bur... a quick search showed that clones have no serial num at all (?)

20160829_190102.jpg
 
Status
Not open for further replies.

Latest threads

Back
Top