Hi lis0r,
I would not dream of telling you there is no problem with the PIC chip(s), but I can tell you that I am very procedural about writing the chips. I write/run a pin scan on a test fixture, then move the chip to a customized core to send up the bootloader and MIOS. That rig lets me watch all of them boot/run/generate the proper sysex/drive an LCD.
Definitely not trying to blameshift in any way by saying this but I thought some insight into the treatment they received here at the kitmill might help. :turned:
Core 3 works, however, cores 0-2 don’t. I can query them, but an attempt to upload firmware bombs out 20-40% of the way through. They sporadically but rapidly spit out the following MIDI data:
f0 00 00 7e 40 00 0e 0b 01 f7
f0 00 00 7e 40 00 01 f7
I’m assuming they’re rebooting? I’ve tried swapping core chips, and the good core works in whichever slot it’s in. The voltages to the PICs seem steady.
f0 00 00 7e 40 00 01 f7 is an upload request and the timing of the message is a clue to what is going on.
Bootloader only will generate this message over and over every 2 seconds until MIOS is loaded. (with the chips I ship this would only happen if the flash was corrupted/MIOS overwritten somehow)
Bootloader + MIOS will generate the message only once at startup.
Bootloader + MIOS + app will generate the message only once at startup.
So if the message is not repeating @ 2 second intervals or it is sending the message at random times not just once at boot it looks like a random reset issue.
The most common cause for random resets on a good supply with the SID app is the CAN bus termination - on the 6582 baseboard this is the 1N4148 “D1” diode under each PIC and “R80” located between PIC 1 and PIC 2. If these are missing/wrong or the diode(s) are backwards the SID app will reset at random even on a clean power supply.
Some LCDs if wired for 8 bit mode instead of 4 bit will cause the same symptoms.
The upload problem(s) will likely change or go away once the reboot issue is sorted - failed uploads are a common symptom of a CAN bus termination issue.
App cloning works great for some but fails for others, and some have trouble with straight up SYSEX app uploading via MIOS Studio for the 2nd 3rd and 4th PICs. The quickest work around for this is usually to swap 0001-0003 into PIC 0000’s socket one at a time to do the app upload, setting the SYSEX address in MIOS Studio to match the address for each chip (last two digits of the PIC ID string on the label).
I’m going to borrow a PICkit3 from work and see if I can reflash them back to “new”, but I’m not hopeful. Have I just got bad PICs? 
If you go this direction I have some PICkit-ware binaries ready to load/burn without configuration issues I can send if you want them… Setting the ID string for the bootloader programming ranges from easy to impossible depending on which PICkitware you are using.
Also, on one of the PICs, I’m pretty sure I accidentally wired 9v on U1_SID to pin 8 - is there any chance this hasn’t damaged the PIC, or should I just order a new one now?
Over the years I have seen PICs endure some amazing abuse in builds gone wrong and still work great… I would say wait until the reboot and upload issues are solved then the test tone app will help determine if there is a bad pin/port.
Let us know how it goes!
Best regards
Tim