chips dsPIC que se ejecutan a una fracción de la velocidad normal

9

Tengo dos PCBs. Uno tiene un dsPIC30F6012a, el otro un dsPIC30F6015. Ambos se están programando desde proyectos HEX independientes en MPLAB X, usando un PICkit 3. Ambos firmware se han aplicado a docenas de unidades antes de este punto sin dificultad. Actualmente, el firmware está funcionando correctamente cuando está programado desde todas las PC menos una. En esa PC, comenzando ayer , ambos firmwares programan sin error obvio, pero se ejecutan a una velocidad normal de aproximadamente 1/20. Antes de ayer, esa PC también programaba estas placas sin problemas.

Las pantallas de inicio tardan dos minutos en lugar de cinco segundos, las luces parpadean muy lentamente y, sin embargo, todo funciona correctamente. Es casi como si se hubieran alterado los bits de configuración del oscilador, pero no conozco ningún lugar en MPLAB X que se pueda realizar en un proyecto independiente.

Por lo tanto, dos firmwares diferentes, en dos chips diferentes, en múltiples instancias del mismo diseño de PCB, ejecutándose a diferentes velocidades dependiendo solo de la PC que se use para programar. Reprogramar una placa lenta en una PC "buena" soluciona el problema; la reprogramación de esa misma placa en la PC "mala" lo devuelve. Todo lo que puedo imaginar es que en esa PC alguien pulsó el botón "hacerlo lentamente", pero no puedo encontrar nada etiquetado así. (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 arregla, todavía no estoy contento de no saber qué está pasando. ¿Alguien tiene alguna idea de este problema?

    
pregunta Stephen Collings

1 respuesta

1

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

No ha dicho que si la reprogramación de una de las tarjetas 'malas' en una PC 'en funcionamiento' soluciona el problema. Inténtalo.

Otra cosa que podría hacer (si no usa el código de protección) es leer el archivo HEX de una configuración de "funcionamiento" y colocarlo en una de las tarjetas que no funcionan correctamente. Esto debería eliminar el cambio de código como una de las incertidumbres.

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

EDITAR: es hora de asegurarse de que las distintas instalaciones de MPLAB X coincidan en todas las PC, ¿son la misma revisión? ¿Son las últimas revisiones?

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

Hace poco tuve una situación similar (ahora que me di cuenta de ello) 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 lo haría en otra máquina con MPLAB 8 v8.50: el código parecía estar ejecutándose 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. Raro.

    
respondido por el Adam Lawrence

Lea otras preguntas en las etiquetas