I recently taught a class utilizing PIC chips and MPlabx. This is the first time I used PIC chips in about 20 years. I have to say, it has been one of the most frustrating experiences I have had programming chips in a very long time. MPlabx is a modified version of Netbeans, with which I am intimately familiar with as I used it for my graduate work. My class had an impossibly hard time consistently programming chips. This page documents some of the ways we fixed the problem.
While coding, sometimes, seemingly randomly, MPLabx will start throwing underlining things and start throwing errors such as “TRISA no defined.” It is as if the link to the libraries gets severed. I have no clue why this happens, but two things seem to fix it. 1. Save the file you are editing because sometimes it is just that the changes you’ve made have not been saved and it can’t find some of the declarations for things. 2. When the problem persists or actually won’t compile, then you have to Restart MPlabx. Once it loads up again, it will re-register all the library paths and all is well. If this doesn’t fix the problem, then check the errors and make sure you have the correct number of curly bracket “}” and in the right places. Remember, no executable code can exist outside of functions except global declarations.
Programming issues:
One of the biggest issues was powering the circuit. By default, every project expects your circuit to be powered externally. The programmer even has a pin dedicated to sensing this voltage and stopping everything if it isn’t sensed. You have 2 options. Either power the circuit externally, or you can go to project properties, Conf–>PIckit4 (or whatever programmer you have) and select “power” from the dropdown and checking to power the board. Check the box next to “Power target from…”
This will only work if your circuit is low-powered. If you need a significant amount of power, then you must power the board separately and make sure this setting is NOT checked. Sometimes this can prevent the chip from programming, but more on this later.
Programming Pins:
The programmers only have a few pins that are used on the processor, but those are very important.
Memclr/Reset: This pin basically tells the processor it is being reprogrammed. (There’s more to it, but out of the scope of this post).
Target voltage: This senses whether or not the processor has power. If not, then the programmer won’t attempt to talk to it and will instead error out.
PGD: Programmer data. This is often on a standard port pin, so if programming keeps failing, isolate this pin form anything else. ie. remove all externally connected things like buttons, LEDs, whatever else you might have connected to this pin and only connect the programmer.
PGC: Programmer clock. The same applies from above.
Gnd: Communication required a shared ground so make sure this is connected correctly.
If the PGD, PGC, and GND are not connected correctly, you’ll often get the following type of error:
Target Device ID (0x0) is an Invalid Device ID. Please check your connections to the Target Device.
Each processor has a special register that contains a number identifying what type of chip it is. The programmer requests this info before programming so it won’t accidently brick the chip by writing to it in the wrong places. The device ID is NEVER 0x0 for any processor. If you see this error that means that the programmer was unable to get a correct value from the PGD pin. Check your connections for shorts, opens, and remove any circuitry attached to the programming pins except the programmer itself.
Otherwise, you might get something like the following:
Target Device ID (0x6750000) is an Invalid Device ID. Please check your connections to the Target Device.
This error shows that a value number was returned, however this doesn’t match the chip your project is set to compile for. Check your program properties and make sure the chip number matches the part number labeled on the processor itself.
Programmer Quality:
While not do or die, I will say that a good programmer is helpful. Don’t get me wrong, I’ve cobbled together some super janky programmers back in the day that have worked, but having a quality device certainly helps troubleshoot. We originally started using PICkit3 programmer (without the Microchip logo, which I think indicates they are clones). For about 2 weeks, while it worked about 80% of the time on my laptop, having a class of laptops with different configurations ,etc. led us to have such problems that I searched for other solutions. The first thing that helped was to use the MicrostickII and solder up a converter board that converted the programming pinout to a programing cable. This solved the problem for a few students.
Eventually I was approved to buy official PICkit4 programmers, which seemed to help even more. However unexpectedly and randomly, some folks still had a warning pop up suddenly, after successfully programming multiple times in a row, which prevented them from having success. There would be absolutely no hardware or settings changes, only small tweaks to the code, but suddenly the chips would refuse programming.
Though there were multiple error, the most common was
Programming did not complete.
You are trying to change protected boot memory. In order to do this you must select the “Boot, Secure and General Segments” option on the debug tool Secure Segment properties page.
Attempt 1 (rarely successful): Some folks online suggested manually erasing the chip first, then trying to program. This rarely works.
Attempt 2 (sometimes successful): Maybe your circuit requires more power than your programmer or USB can provide. Go in the settings as described above and uncheck “Power target circuit…” and make sure to provide an external power source.
Attempt 3 (sometimes successful): Again, this is after multiple successful attempts and no hardware or program setting changes. My predecessor told me that when this happens, the fix is typically to do the following: Open the project properties, Select Conf–>PicKit4 (or whatever programmer you have) then select “Memories” from the dropdown and change it from “Automatic” to “Manual” then click “Apply” Then click it back to “Automatic” and apply then click OK. This seems to work sometimes…
Attempt 3 (the actual fix): Well, I could have just read the error message because it tells you just what to do… kind of. Open project properties: –>Conf->PICkit4 then from the dropdown, select “Secure Segment” and change the “Segments to be programmed” to “Boot, Secure and General Segments”
Why is this not default? Why does it work multiple times, then suddenly require this change? Who knows? I would absolutely love an explanation for this behavior.
After successfully programming for a n hour or so, a new error I inexplicably received suddenly appears as follows:
Erasing…
[config mem] 0xf80000, expected 0xcf, got 0x0.
You have set the program speed to Normal. The circuit on your board may require you to slow the speed down. Please change the setting in the tool properties to low and try the operation again.
Programming did not complete.
Changing programing speeds does nothing:
Erasing…
[config mem] 0xf80000, expected 0xcf, got 0x0.
Programming did not complete.
If you run into this, disconnect power to your chip and programmer, and plug it all back in. Sometimes this requires you just unplug your programmer from USB and replug the programmer to your computer. Again, this happens when I’ve been successfully programming for an hour or so, literally nothing changes except tweaks to my code, and suddenly nothing wants to work. No explanation for as to why this happens.