Chip dsPIC in esecuzione a una frazione della velocità normale

Ho due PCB. Uno ha un dsPIC30F6012a, l'altro un dsPIC30F6015. Entrambi sono programmati da progetti HEX autonomi separati in MPLAB X, usando un PICkit 3. Entrambi i firmware sono stati applicati a dozzine di unità prima di questo punto senza difficoltà. Attualmente, il firmware funziona correttamente quando programmato da tutti i PC tranne uno. Su quel PC, a partire da ieri , entrambi i firmware programmano senza errori evidenti, ma eseguono a circa 1/20 di velocità normale. Prima di ieri, quel PC ha anche programmato queste schede senza problemi.

Gli schermi Splash impiegano due minuti anziché cinque secondi, le luci lampeggiano molto lentamente e tuttavia tutto funziona correttamente. È quasi come se i bit di configurazione dell'oscillatore fossero stati modificati, ma non sono a conoscenza di alcun punto di MPLAB X che possa essere eseguito su un progetto autonomo.

Quindi due firmware diversi, su due chip diversi, su più istanze dello stesso design PCB, che funzionano a velocità diverse a seconda del PC utilizzato per programmarli. La riprogrammazione di una scheda lenta su un PC "buono" risolve il problema; riprogrammando quella stessa scheda sul PC "cattivo" la riporta. Tutto quello che riesco a capire è che su quel PC qualcuno ha premuto il pulsante "Fallo lentamente", ma non riesco a trovare nulla di simile. (I nostri tecnici sono piuttosto creativi, però). Attualmente sto disinstallando MPLAB X, cancellando le impostazioni dell'utente e reinstallando una versione più recente. (Passando dall'1.3 all'1.6.) Ma anche se ciò lo risolve, non sono ancora felice di non sapere cosa sta succedendo. Qualcuno ha qualche idea su questo problema?

In MPLAB X, i bit di configurazione non possono essere impostati separatamente dal codice (come MPLAB 8 utilizzato per consentirti di farlo). L'unico modo in cui i bit di configurazione potrebbero essere "sbagliati" è se qualcuno ha modificato il codice. Dato che stai usando un progetto di file HEX autonomo, questo è improbabile.

Non hai detto se riprogrammare una delle schede "cattive" su un PC "funzionante" risolve effettivamente il problema. Provalo.

Un'altra cosa che potresti fare (se non usi la protezione del codice) è rileggere il file HEX da un'impostazione "funzionante" e inviarlo in una delle schede malfunzionanti. Ciò dovrebbe eliminare la modifica del codice come una delle incertezze.

Un altro (improbabile) scenario è che il tuo stock dsPIC copra più revisioni e che un cambiamento graduale abbia in qualche modo invalidato il tuo codice. Assicurarsi che i numeri di parte IC siano corretti e, quando PICkit3 si collega, dovresti vedere un codice di revisione che puoi fare riferimento alla revisione del silicio.

EDIT: Ora è il momento di assicurarsi che le varie installazioni di MPLAB X corrispondano su tutti i PC: sono la stessa revisione? Sono l'ultima revisione?

Ogni volta che c'è una nuova versione di MPLAB X, il firmware PICkit3 tende ad essere aggiornato - potrebbe esserci un bug o incompatibilità con il vecchio firmware PICkit3 e il tuo file HEX.

Recentemente ho avuto una situazione simile (ora che mi è appena venuto in mente - duh) in cui un file HEX che ho generato sulla mia macchina con MPLAB X e XC16 si sarebbe programmato correttamente sulla mia macchina, ma non su un'altra macchina usando MPLAB 8 v8. 50 - il codice sembrava funzionare più lentamente (i LED di inizializzazione sembravano lenti). Quando quel PC è stato aggiornato con MPLAB 8 v8.88, usando lo stesso programmatore e lo stesso file HEX, le cose hanno ripreso a funzionare. Strano.