Electronic – dsPIC chips running at a fraction of normal speed

microchipmicrocontrollermplabpic

I have two PCBs. One has a dsPIC30F6012a, the other a dsPIC30F6015. Both are being programmed from separate standalone HEX projects in MPLAB X, using a PICkit 3. Both firmwares have been applied to dozens of units prior to this point without difficulty. Presently, the firmware is operating correctly when programmed from all PCs but one. On that one PC, starting yesterday, both firmwares program without obvious error, but execute at approximately 1/20 normal speed. Prior to yesterday, that PC also programmed these boards without problem.

Splash screens take two minutes instead of five seconds, lights blink very slowly, and yet besides this everything operates correctly. It's almost as if the oscillator configuration bits have been altered, but I'm not aware of anywhere in MPLAB X that can be done to a standalone project.

So two different firmwares, on two different chips, on multiple instances of the same PCB design, running at different speeds depending only on the PC being used to program them. Reprogramming a slow board on a "good" PC fixes the problem; re-reprogramming that same board on the "bad" PC brings it back. All I can figure is that on that one PC someone hit the "make it go slowly" button, but I can't find anything labeled that. (Our techs are pretty creative, though.) I'm presently uninstalling MPLAB X, wiping the user settings, and reinstalling a more recent version. (Going from 1.3 to 1.6.) But even if that fixes it, I'm still not happy not knowing what's going on. Does anyone have any insight into this problem?

Best Answer

In MPLAB X, the config bits cannot be set separately from the code (like MPLAB 8 used to let you do). The only way the config bits could be 'wrong' is if someone modified the code. Since you're using a standalone HEX file project, this is unlikely.

You haven't said if reprogramming one of the 'bad' boards on a 'working' PC actually fixes the issue. Give that a try.

Another thing you could do (if you don't use code protect) is read back the HEX file from a 'working' setup and flash that into one of the malfunctioning boards. This should eliminate code change as one of the uncertainties.

Another (unlikely) scenario is that your dsPIC stock covers multiple revisions, and a stepping change has somehow invalidated your code. Make sure the IC part numbers are correct, and when the PICkit3 connects, you should see a revision code that you can cross-reference to the silicon revision.

EDIT: It's now time to make sure that the various installations of MPLAB X are matching on all the PCs - are they the same revision? Are they the latest revision?

Whenever there's a new version of MPLAB X, the PICkit3 firmware tends to get upgraded - there may be a bug or incompatibility with older PICkit3 firmware and your HEX file.

I had a similar situation recently (now that it just dawned on me - duh) where a HEX file that I generated on my machine with MPLAB X and XC16 would program correctly on my machine, but would not on another machine using MPLAB 8 v8.50 - the code seemed to be running slower (initialization LEDs seemed sluggish). When that PC was updated with MPLAB 8 v8.88, using the same programmer and the same HEX file, things started working again. Weird.