chips dsPIC funcionando a una fracción de la velocidad normal

Tengo dos PCB. Uno tiene un dsPIC30F6012a, el otro un dsPIC30F6015. Ambos se están programando desde proyectos HEX independientes por separado en MPLAB X, utilizando un PICkit 3. Ambos firmwares se han aplicado a docenas de unidades antes de este punto sin dificultad. Actualmente, el firmware funciona correctamente cuando se programa desde todas las PC menos una. En esa PC, a partir de ayer , ambos programas de firmware sin error obvio, pero se ejecutan a aproximadamente 1/20 de la velocidad normal. Antes de ayer, esa PC también programó estas placas sin problema.

Las pantallas de bienvenida tardan dos minutos en lugar de cinco segundos, las luces parpadean muy lentamente y, además, todo funciona correctamente. Es casi como si los bits de configuración del oscilador hubieran sido alterados, pero no estoy al tanto de ninguna parte de MPLAB X que se pueda hacer en un proyecto independiente.

Entonces, dos firmwares diferentes, en dos chips diferentes, en múltiples instancias del mismo diseño de PCB, funcionando a diferentes velocidades dependiendo solo de la PC que se use para programarlos. La reprogramación de una placa lenta en una PC "buena" soluciona el problema; reprogramar esa misma placa en la PC "mala" lo trae de vuelta. Todo lo que puedo imaginar es que en esa PC alguien presionó el botón "hazlo ir despacio", pero no puedo encontrar nada etiquetado. (Sin embargo, nuestros técnicos son bastante creativos). Actualmente estoy desinstalando MPLAB X, borrando la configuración del usuario y reinstalando una versión más reciente. (Pasando de 1.3 a 1.6.) Pero incluso si eso lo soluciona, todavía no estoy feliz de no saber qué está pasando. ¿Alguien tiene alguna idea de este problema?

En MPLAB X, los bits de configuración no se pueden establecer por separado del código (como MPLAB 8 solía permitirte). La única forma en que los bits de configuración podrían estar 'incorrectos' es si alguien modifica el código. Dado que está utilizando un proyecto de archivo HEX independiente, esto es poco probable.

No ha dicho si la reprogramación de una de las placas 'malas' en una PC 'en funcionamiento' realmente soluciona el problema. Pruébalo

Otra cosa que podría hacer (si no usa protección de código) es leer el archivo HEX desde una configuración 'funcional' y actualizarlo en una de las placas que funcionan mal. Esto debería eliminar el cambio de código como una de las incertidumbres.

Otro escenario (poco probable) es que su stock dsPIC cubre múltiples revisiones, y un cambio gradual ha invalidado de alguna manera su código. Asegúrese de que los números de pieza de IC sean correctos, y cuando el PICkit3 se conecte, debería ver un código de revisión que pueda hacer referencia cruzada a la revisión de silicio.

EDITAR: ahora es el momento de asegurarse de que las diversas instalaciones de MPLAB X coincidan en todas las PC: ¿son la misma revisión? ¿Son la última revisión?

Cada vez que hay una nueva versión de MPLAB X, el firmware PICkit3 tiende a actualizarse; puede haber un error o incompatibilidad con el firmware PICkit3 anterior y su archivo HEX.

Recientemente tuve una situación similar (ahora que me di cuenta), donde un archivo HEX que generé en mi máquina con MPLAB X y XC16 se programaría correctamente en mi máquina, pero no en otra máquina que usa MPLAB 8 v8. 50 - el código parecía funcionar más lentamente (los LED de inicialización parecían lentos). Cuando esa PC se actualizó con MPLAB 8 v8.88, usando el mismo programador y el mismo archivo HEX, las cosas comenzaron a funcionar nuevamente. Extraño.