puces dsPIC fonctionnant à une fraction de la vitesse normale

J'ai deux PCB. L'un a un dsPIC30F6012a, l'autre un dsPIC30F6015. Les deux sont programmés à partir de projets HEX autonomes séparés dans MPLAB X, en utilisant un PICkit 3. Les deux firmwares ont été appliqués à des dizaines d'unités avant ce point sans difficulté. Actuellement, le firmware fonctionne correctement lorsqu'il est programmé à partir de tous les PC sauf un. Sur ce PC, à partir d'hier , les deux firmwares programment sans erreur évidente, mais s'exécutent à environ 1/20 vitesse normale. Avant hier, ce PC avait également programmé ces cartes sans problème.

Les écrans de démarrage prennent deux minutes au lieu de cinq secondes, les lumières clignotent très lentement, et en plus de cela, tout fonctionne correctement. C'est presque comme si les bits de configuration de l'oscillateur avaient été modifiés, mais je ne connais aucun endroit dans MPLAB X qui puisse être fait pour un projet autonome.

Donc, deux firmwares différents, sur deux puces différentes, sur plusieurs instances de la même conception de PCB, fonctionnant à des vitesses différentes en fonction uniquement du PC utilisé pour les programmer. Reprogrammer une carte lente sur un "bon" PC résout le problème; reprogrammer cette même carte sur le "mauvais" PC la ramène. Tout ce que je peux comprendre, c'est que sur ce PC, quelqu'un a appuyé sur le bouton "faire avancer lentement", mais je ne trouve rien étiqueté comme ça. (Nos techniciens sont assez créatifs, cependant.) Je désinstalle actuellement MPLAB X, efface les paramètres utilisateur et réinstalle une version plus récente. (Passer de 1.3 à 1.6.) Mais même si cela le corrige, je ne suis toujours pas content de ne pas savoir ce qui se passe. Quelqu'un at-il une idée de ce problème?

Dans MPLAB X, les bits de configuration ne peuvent pas être définis séparément du code (comme MPLAB 8 utilisé pour vous permettre de le faire). La seule façon dont les bits de configuration pourraient être «incorrects» est que quelqu'un modifie le code. Étant donné que vous utilisez un projet de fichier HEX autonome, cela est peu probable.

Vous n'avez pas dit si la reprogrammation de l'une des «mauvaises» cartes sur un PC «en état de marche» résout réellement le problème. Essayez ça.

Une autre chose que vous pourriez faire (si vous n'utilisez pas de protection de code) est de relire le fichier HEX à partir d'une configuration «fonctionnelle» et de le flasher sur l'une des cartes défectueuses. Cela devrait éliminer le changement de code comme l'une des incertitudes.

Un autre scénario (peu probable) est que votre stock dsPIC couvre plusieurs révisions et qu'un changement progressif a en quelque sorte invalidé votre code. Assurez-vous que les numéros de pièce IC sont corrects, et lorsque le PICkit3 se connecte, vous devriez voir un code de révision que vous pouvez renvoyer à la révision de silicium.

EDIT: Il est maintenant temps de s'assurer que les différentes installations de MPLAB X correspondent sur tous les PC - s'agit-il de la même révision? S'agit-il de la dernière révision?

Chaque fois qu'il y a une nouvelle version de MPLAB X, le micrologiciel PICkit3 a tendance à être mis à niveau - il peut y avoir un bogue ou une incompatibilité avec l'ancien micrologiciel PICkit3 et votre fichier HEX.

J'ai eu récemment une situation similaire (maintenant qu'elle vient juste de se faire jour - duh) où un fichier HEX que j'ai généré sur ma machine avec MPLAB X et XC16 se programme correctement sur ma machine, mais pas sur une autre machine utilisant MPLAB 8 v8. 50 - le code semblait fonctionner plus lentement (les LED d'initialisation semblaient lentes). Lorsque ce PC a été mis à jour avec MPLAB 8 v8.88, en utilisant le même programmeur et le même fichier HEX, les choses ont recommencé à fonctionner. Bizarre.