Zawsze uważałem avr-y za bezproblemowe procesory do programowania, do wczoraj. Trochę zeszło zanim znalazłem przyczynę. Flash programuje się ok z eepromem są problemy używałem usbasp i klona mkII z różnymi programami np. sina prog, bascom. Wszędzie ten sam problem z eepromem. Najczęściej niezgodność na adresie 0400hex. Jak zaczełem przeglądać zawartość eepromu w bascomie i innym programiku wyszło co jest problemem, warto spojrzeć na zrzuty a i b. Widać w nich, że w bascomie (i nie tylko) pamięć zapełniona jest do 1kb (0400hex). W innym programie pogląd eep pokazuje, że jest zapełniona do adresu 0280. Znalazłem jakiś stary programator na avrospII i poszło od razu. Oczywiście zajęcie pamięci do adresu 0280hex. Zaprogramowałem nim i jest ok. Może komuś się to przyda. Może ktoś zna przyczynę? Wydaje mi się zdaje przyczyną może być inny format pliku ale mogę się mylić.
Jesli on ma 1KB to nie ma adresu 0x400, jest tylko 0x3FF
), w informatyce stosuje sie numerację logiczną. Nie wiem czy dobrze zrozumiałem chodzi oto że potrzebujesz do 0x280 a on zapisuje do końca? to typowe gdy programista programatora się nie przyłoży i kopiuje cały bufor razem ze śmieciami, ewentualnie może być błąd w deklaracjach lub bibliotekami rozmiaru EEPROMU. Podobne problemy zdarzały mi się jak nadpisałem przypadkowo adresy deklaracjami przydzielania adresów .org, przyczyn mozę być wiele tak naprawdę.
Tomku źle mnie zrozumiałeś, to jest gotowy plik eeprom od działającego programu. Niezgodność jest na adresie 0x400 bo jest przekroczony rozmiar pamięci podczas programowania. W kilku programach pokazuje jego rozmiar (pliku eep) jako większy od 1k a w innych do adresu 0x280 czyli ok. Problem leży po stronie programu programującego. W pierwszej kolejności sprawdzę jego sumy kontrolne ale to w wolnym czasie.
Witam.
Z Twoich zrzutów wynika, że załadowałeś do bufora EEPROMa jakieś dane do adresu 3FFh i to jest prawidłowe.
Poniżej jest napisane, że plik KALIBRACJA.EEP nie istnieje, więc nie wiem co tam załadowałeś
Gdybyś dołączył rzeczywiste pliki można by było się coś więcej dowiedzieć bo np. pliku z rozszerzeniem .EEP z PONY PROGa nie załadujesz do EXTREME BURNERA - chociaż ma dobre rozszerzenie, lecz ma złą wielkość i na początku zawatrości Pony Prog zapisuje typ programowanego chipu.
Pozdrawiam,
Rafale nie ma sie czym przejmować, nie da się przekroczyć rozmiaru EPPROMU bo fizycznie tam nic nie ma
) Zapis pod adr. 0x400 to zapis pod adres zerowy bo to po prostu 10 bitowy rejestr wskaźnika EEPROMU w uC. Taki błąd powinien wyłapać kompilator (jeśli rozmiar EPPROMU w bibliotece jest OK). Rózne programy po prostu odczytują śmieci poza zakresem pamieci, tak jest np. w AVR STUDIO... Programista zakłada że znasz rozmiar EEPROMU i nie interesuje go co jest dalej. A wystarczy tylko wyczyścić bufor przed odczytem. Zrestartuj program i zobaczysz że tam są już zupełnie inne wartości.
Sumy kontrolne powinien wyłapać loader i od razu zgłosić błąd, także tu raczej bym nie szukał.
Tomku nie rozumiesz. Przyjrzyj się rysunkom A i B to jest ten sam wsad przed zaprogramowaniem podglądany za pomocą różnych programów do programowania. To, że zgłasza błąd na zakresie 0400hex po zaprogramowaniu wynika z tego, że część programów do ładowania wsadu twierdzi, że coś tam jest a inne twierdzą, że dane kończą się na adresie 027F hex. To nie są źle odczytane dane z eepromu a dane źle widziane przez program do programowania.
Bo w drugim przykładzie chyba odczytujesz flash
) a nie EEPROM, i on się kończy 0x28F (nie 27F). W A pisze że zaprogramowano 0 wiec po prostu odczytujesz śmiecie z bufora programatora, gdyby programista wyczyścił bufor przed odczytem to byś widział same zera albo FFki . Ściągnij EEPROM do pliku i porównaj to co ściagnałeś z oryginalnym plikiem do zaprormamowania. Niektóre programy są napisane na kolanie.
Tomku uwierz mi nie masz racji. To, że podejrzałem plik eep jako flash a nie eprom nie ma żadnego znaczenia oba zapisane są w formacie intel hex. Podejrzałem go jako flash bo ten programator nie umożliwiał obsługi tego procesora a chodziło mi tylko o odczytanie zawartości pliku. Zreszo podglądałem ten plik rodzajem edytora tekstowego plik eepromu kończy się na adresie 027F hex. Zastanów się dlaczego na kilku programach zgłasza błąd porównania na eepromie dopiero na adresie 0400hex a nie wcześniej -to nie są śmieci tylko tak plik jest widoczny potwierdza to odczyt w bascomie -patrz a. Również program którym udało się zaprogramować wreszcie układ stwierdził, że dane kończą się na adresie 0280hex. Żeby jednak uciąć Twoje spekulacje jutro po powrocie umieszczę tutaj ten plik.
Tomku załączam plik eep spakowany przejrzyj pod np bascomem i np. w jakimś edytorze.
Witam.
Bascom domyślnie plik EEP traktuje jako plik binarny, a Ty dajesz mu hex ( $eepromhex
Informuje kompilator, aby plik EEP z zawartoscią pamieci EEPROM tworzył w formacie HEX (domyślnie tworzy w formacie binarnym) dlatego nie go załaduje.
[
attachment=8699] [
attachment=8700] [
attachment=8701] [
attachment=8702]
Włodku czy dobrze rozumiem by załadować ten plik za pomocą bascoma do procesora (nawet nie wiem w czym to jest napisane) należy dokonać konwersji pliku hex z zawartością eepromu do formatu binarnego i dopiero go załadować? Jeśli tak to mógłbyś polecić jakiś program do konwersji hex -bin. Ten sam problem miałem z sina prog.