logo elektroda
logo elektroda
X
logo elektroda
Adblock/uBlockOrigin/AdGuard mogą powodować znikanie niektórych postów z powodu nowej reguły.

[AVR] - Bootloader, FLIP - niechciane kasowanie EEPROM

MateuszW_ 31 Paź 2015 02:30 999 3
  • #1 15109923
    MateuszW_
    Poziom 8  
    Witam
    Mam pewien problem z pamięcią EEPROM przy programowaniu poprzez FLIP. Otóż robiąc pełną sekwencję (erase, blank check, program, verify) przy programowaniu do flasha usuwa się przy okazji cała zawartość EEPROM. Jest to niezwykle denerwujące, bo w tej pamięci trzymam całą konfigurację programu i muszę ją po zaprogramowaniu znowu wprowadzać. Zresztą takie zachowanie przeczy idei pamięci EEPROM - ma ona się zachowywać przy przeprogramowywaniu, ma pamiętać ustawienia niezależnie od wszystkiego!

    Zauważyłem, że usuwanie pamięci EEPROM następuje przy operacji erase. Nie mam pojęcia dlaczego mając wybraną pamięć flash (na tym przycisku poniżej loga atmela) kasuje się zarówno flash, jak i EEPROM. Tak więc postanowiłem nie robić operacji erase (i blank chcek oczywiście), żeby nie kasować EEPROMa. Robię więc tylko program i verify.

    I tu pojawia się pytanie. Czy pominięcie operacji erase przy programowaniu jest złe? Czy bez wykasowania pamięci przed programowaniem może się coś popsuć? Jeśli nie, to pewnie jest to rozwiązanie problemu - nie będę robił erase, a EEPROM zostanie nienaruszony. Jesli jednak erase jest wskazane, to jest większy problem.

    Znalazłem, że aby pozbyć się kasowania eeprom przy erase należy zmienić kod bootloadera - jest taka funkcja:
    Kod: C / C++
    Zaloguj się, aby zobaczyć kod

    i trzeba wywalić jedną linijkę. Jednak problemem jest skompilowanie tego ponownie. Ludzie piszą, że to trzeba skompilować w jakimś IAR. Czy to jest po prostu jakiś inny program do klepenia, niż AVR studio, nie mający z nim nic wspólnego? Nie umiem tego znaleźć... Dlaczego Atmel korzysta do kompilowania bootloadera z jakiegoś kompilatora konkurencyjnej firmy, a nie swojego własnego?
  • Pomocny post
    #2 15110385
    tmf
    VIP Zasłużony dla elektroda
    Erase dotyczy całego procka, więc i EEPROM. Jeśli chcesz zachować EEPROM to albo nie wykonuj erase, nie ma to znaczenia w większości przypadków dla programowania FLASH, albo podczas programowania programuj i FLASH i EEPROM.
    Co do kompilacji - wymaga IAR zapewne dlatego, żeby zmieścić się z kodem w obszarze bootloadera. Niektóre wersje gcc generują dłuższy kod wynikowy, który nie mieści się w bootloaderze. Niemniej użycie najnowszych wersji gcc z odpowiednimi opcjami powinno dać radę, o ile kod bootloadera nie wykorzystuje jakiś opcji specyficznych dla IAR. Wtedy trzebaby go przeportować, co wymaga właściwie kosmetycznych zmian. Niemniej roziwązanie typu nie robimy erase jest ok, o ile twój program z jakiegoś powodu (np. liczenie CRC) nie zakłada, że stan nieużywanych komórek pamięci FLASH jest równy 0xff.
  • #3 15111199
    MateuszW_
    Poziom 8  
    Ok, rozumiem. A czy brak wyzerowania pozostałych komórek nie ma negatywnego wpływu na np odporność na błędy? Jeśli procesor na skutek jakiś np zakłóceń wskoczy w zły obszar pamięci i napotka tam kod, to zacznie robić głupoty. A jak będzie 0xff, to (chyba) nic nie będzie robił.

    Opcja z programowaniem flasha oraz eeprom równocześnie odpada, bo eeprom jest edytowany przy zmianie ustawień w urządzeniu podczas działania programu, a wiec na kompie miałbym jakieś nieaktualne wartości, które bym wgrywał. A do tego takie ciągłe programowanie eepromu przecież skraca jej żywotność.
  • #4 15111281
    tmf
    VIP Zasłużony dla elektroda
    MateuszW_ napisał:
    Ok, rozumiem. A czy brak wyzerowania pozostałych komórek nie ma negatywnego wpływu na np odporność na błędy? Jeśli procesor na skutek jakiś np zakłóceń wskoczy w zły obszar pamięci i napotka tam kod, to zacznie robić głupoty. A jak będzie 0xff, to (chyba) nic nie będzie robił.


    Jeśli w wyniku zakłóceń procesor idzie w maliny to właściwie nie ma żadnego znaczenia co jest w reszcie pamięci. Równie dobrze mógłby zacząć wykonywanie twojego kodu w losowym miejscu, bo zapewne będzie miało skutki równie opłakane. IMHO należy raczej wyeliminować możliwość pójścia procka w maliny, ew. uodpornić też resztę układu na taką sytuację, jeśli oczywiście aplikacja jest tego warta.
REKLAMA