9

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?

Stephen Collings
  • 17,373
  • 17
  • 92
  • 180
  • Does the PC do a verify after programming? You can check the configuration bits with that, because it looks like that's the problem. –  Feb 08 '13 at 15:29
  • Verify is run, yes. No errors were thrown, so I assumed that included the config bits, but I didn't check for the manually. Probably should have, just for more data, but I was pressed for time and went straight for the uninstall/reinstall solution. Waiting for word on if that worked or not! – Stephen Collings Feb 08 '13 at 15:36
  • Will a board programmed by a slow-inducing PC verify on a "good" PC? – Chris Stratton Feb 08 '13 at 20:44
  • Unfortunately (ha!) the reinstall fixed the problem, so I can't gather more data... makes it hard to get a definitive answer! – Stephen Collings Feb 08 '13 at 21:57
  • This question reads like something out of a tech-themed *The Onion*. – Kevin Chen May 22 '13 at 06:15

1 Answers1

1

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.

Adam Lawrence
  • 32,921
  • 3
  • 58
  • 110
  • I did reprogram the same board on "good" and "bad" PCs, and the problem came and went following the PC that was used to program the board. I've edited the question to reflect this. – Stephen Collings Feb 08 '13 at 16:47