Układy dsPIC działające z ułamkiem normalnej prędkości

Mam dwie płytki drukowane. Jeden ma dsPIC30F6012a, drugi dsPIC30F6015. Oba są programowane z oddzielnych niezależnych projektów HEX w MPLAB X, przy użyciu PICkit 3. Oba oprogramowanie układowe zostało bez problemu zastosowane do kilkudziesięciu jednostek przed tym punktem. Obecnie oprogramowanie układowe działa poprawnie po zaprogramowaniu na wszystkich komputerach oprócz jednego. Na tym jednym komputerze, począwszy od wczoraj , oba programy układowe bez oczywistego błędu, ale działają z prędkością około 1/20 normalną. Przed wczoraj ten komputer bez problemu programował również te płyty.

Ekrany powitalne zajmują dwie minuty zamiast pięciu sekund, kontrolki migają bardzo wolno, a poza tym wszystko działa poprawnie. To prawie tak, jakby bity konfiguracji oscylatora zostały zmienione, ale nie znam nigdzie w MPLAB X, które można by wykonać w niezależnym projekcie.

Tak więc dwa różne oprogramowanie układowe, na dwóch różnych układach, w wielu instancjach tego samego projektu płytki drukowanej, działające z różnymi prędkościami, zależnie tylko od komputera używanego do ich programowania. Przeprogramowanie powolnej płyty na „dobrym” komputerze rozwiązuje problem; przeprogramowanie tej samej płyty na „złym” komputerze przywraca ją. Wszystko, co mogę wymyślić, to to, że na tym jednym komputerze ktoś nacisnął przycisk „zrób to powoli”, ale nie mogę znaleźć niczego, co by to oznaczało. (Nasi technicy są jednak dość kreatywni.) Obecnie odinstalowuję MPLAB X, usuwam ustawienia użytkownika i ponownie instaluję nowszą wersję. (Przejście z wersji 1.3 na 1.6.) Ale nawet jeśli to naprawi, nadal nie jestem szczęśliwy, nie wiedząc, co się dzieje. Czy ktoś ma wgląd w ten problem?

W MPLAB X bitów konfiguracyjnych nie można ustawić oddzielnie od kodu (np. MPLAB 8 pozwala na to). Jedynym sposobem, w jaki bity konfiguracji mogą być „niepoprawne”, jest modyfikacja kodu przez kogoś. Ponieważ używasz samodzielnego projektu pliku HEX, jest to mało prawdopodobne.

Nie powiedziałeś, że przeprogramowanie jednej z „złych” płyt na „działającym” komputerze faktycznie rozwiązuje problem. Spróbuj.

Inną rzeczą, którą możesz zrobić (jeśli nie korzystasz z ochrony kodu), jest odczytanie pliku HEX z „działającej” konfiguracji i zapisanie go na jednej z nieprawidłowo działających płyt. To powinno wyeliminować zmianę kodu jako jedną z niepewności.

Innym (mało prawdopodobnym) scenariuszem jest to, że akcje dsPIC obejmują wiele wersji, a stopniowa zmiana w jakiś sposób unieważniła kod. Upewnij się, że numery części układu scalonego są poprawne, a gdy PICkit3 połączy się, powinieneś zobaczyć kod wersji, który możesz odsyłać do wersji krzemowej.

EDYCJA: Nadszedł czas, aby upewnić się, że różne instalacje MPLAB X są takie same na wszystkich komputerach - czy są to te same wersje? Czy to najnowsza wersja?

Ilekroć pojawia się nowa wersja MPLAB X, oprogramowanie PICkit3 ma tendencję do aktualizacji - może występować błąd lub niezgodność ze starszym oprogramowaniem PICkit3 i plikiem HEX.

Niedawno miałem podobną sytuację (teraz, kiedy to właśnie do mnie dotarło - duh), gdzie plik HEX, który wygenerowałem na moim komputerze za pomocą MPLAB X i XC16, programowałby się poprawnie na moim komputerze, ale nie na innym komputerze używającym MPLAB 8 v8. 50 - kod wydawał się działać wolniej (diody LED inicjalizacji wydawały się powolne). Kiedy ten komputer został zaktualizowany do wersji MPLAB 8 v8.88, przy użyciu tego samego programatora i tego samego pliku HEX, wszystko zaczęło znowu działać. Dziwne.