chips dsPIC rodando a uma fração da velocidade normal

Eu tenho dois PCBs. Um tem um dsPIC30F6012a, o outro um dsPIC30F6015. Ambos estão sendo programados a partir de projetos HEX independentes separados no MPLAB X, usando um PICkit 3. Ambos os firmwares foram aplicados a dezenas de unidades antes deste ponto sem dificuldade. Atualmente, o firmware está funcionando corretamente quando programado em todos os PCs, exceto um. Nesse PC, a partir de ontem , os dois firmwares programam sem erro óbvio, mas são executados aproximadamente a 1/20 da velocidade normal. Antes de ontem, esse PC também programava essas placas sem problemas.

As telas de apresentação demoram dois minutos em vez de cinco segundos, as luzes piscam muito lentamente e, além disso, tudo funciona corretamente. É quase como se os bits de configuração do oscilador tivessem sido alterados, mas não conheço nenhum lugar no MPLAB X que possa ser feito em um projeto independente.

Portanto, dois firmwares diferentes, em dois chips diferentes, em várias instâncias do mesmo design de PCB, executando em velocidades diferentes, dependendo apenas do PC que está sendo usado para programá-los. Reprogramar uma placa lenta em um PC "bom" corrige o problema; reprogramar a mesma placa no PC "ruim" traz de volta. Tudo o que posso imaginar é que, naquele PC, alguém apertou o botão "faça devagar", mas não consigo encontrar nada com esse nome. (Porém, nossos técnicos são bastante criativos.) Atualmente, estou desinstalando o MPLAB X, limpando as configurações do usuário e reinstalando uma versão mais recente. (Passando de 1,3 para 1,6.) Mas mesmo que isso resolva, ainda não estou feliz por não saber o que está acontecendo. Alguém tem alguma idéia desse problema?

No MPLAB X, os bits de configuração não podem ser definidos separadamente do código (como o MPLAB 8 usado para permitir isso). A única maneira de os bits de configuração estarem "errados" é se alguém modificou o código. Como você está usando um projeto de arquivo HEX independente, isso é improvável.

Você não disse que se a reprogramação de uma das placas 'ruins' em um PC 'funcional' realmente resolver o problema. Faça uma tentativa.

Outra coisa que você pode fazer (se você não usar a proteção de código) é ler novamente o arquivo HEX de uma configuração 'funcional' e inseri-lo em uma das placas com defeito. Isso deve eliminar a alteração de código como uma das incertezas.

Outro cenário (improvável) é que o seu estoque dsPIC cobre várias revisões e uma mudança gradual de alguma forma invalidou seu código. Verifique se os números de peça do IC estão corretos e, quando o PICkit3 for conectado, você deverá ver um código de revisão que pode fazer referência cruzada à revisão de silício.

EDIT: Agora é hora de garantir que as várias instalações do MPLAB X sejam compatíveis em todos os PCs - são a mesma revisão? Eles são a revisão mais recente?

Sempre que houver uma nova versão do MPLAB X, o firmware do PICkit3 tende a ser atualizado - pode haver um erro ou incompatibilidade com o firmware mais antigo do PICkit3 e seu arquivo HEX.

Recentemente, tive uma situação semelhante (agora que me ocorreu), em que um arquivo HEX que eu gerava na minha máquina com o MPLAB X e o XC16 seria programado corretamente na minha máquina, mas não em outra máquina usando o MPLAB 8 v8. 50 - o código parecia estar mais lento (os LEDs de inicialização pareciam lentos). Quando o PC foi atualizado com o MPLAB 8 v8.88, usando o mesmo programador e o mesmo arquivo HEX, tudo começou a funcionar novamente. Esquisito.