Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

STM32F0 - Zablokowana pamięć Flash

Dahsheg 08 Kwi 2013 16:06 4809 23
  • #1 08 Kwi 2013 16:06
    Dahsheg
    Poziom 9  

    Witam.
    Mam płytkę STM32F0discovey na której jest programator STLink/V2 i mikrokontroler STM32F051R8T6. Od kilku miesięcy bez problemu wgrywałem na niego kod, a dzisiaj nagle napotkałem problem. Środowisko po próbie wygrania nie napisało żadnego komunikatu, ani o powodzeniu ani o błędzie. Natomiast STLink Utility wyrzuca błąd "[0x00000000]: Invalid adress". Przy próbie ręcznej zmiany wartości w pamięci pod początkowymi adresami pojawia się komunikat o błędzie przy zapisie do pamięci.
    Wymazać pamięć można bez problemu, odczytać jej zawartość także.
    Jest jakiś sposób na uratowanie mikrokontrolera?

    0 23
  • #2 08 Kwi 2013 16:08
    mickpr
    Poziom 39  

    Dahsheg napisał:
    Przy próbie ręcznej zmiany wartości w pamięci pod początkowymi adresami pojawia się komunikat o błędzie przy zapisie do pamięci.
    A przy próbie zmiany gdzieś "wyżej" ?

    0
  • #3 08 Kwi 2013 16:50
    Dahsheg
    Poziom 9  

    Powyżej adresu 0x00801000 (lub coś podobnego, nie pamiętam dokładnie a jestem teraz poza domem) spokojnie można ręcznie wpisywać.

    0
  • #4 08 Kwi 2013 17:52
    mickpr
    Poziom 39  

    Dahsheg napisał:
    Od kilku miesięcy bez problemu wgrywałem na niego kod
    Coś mi się nie chce wierzyć, że przekroczyłeś liczbę dostępnych zapisów do Flash. Jednak możliwość taka jak najbardziej istnieje.

    Sprawdź poprawność napięcia zasilania.
    Nie jestem pewny - ale jak widzę z datasheet masz tam "option-bytes" do blokowania zapisu. Czy są puste one puste w STLINK Utility (odblokowany zapis)?
    Spróbuj też zrobić sobie wsad z samymi bajtami 0xFF i nim zaprogramować.

    1
  • #5 08 Kwi 2013 17:55
    Dahsheg
    Poziom 9  

    No po tysiąc razy dziennie nie wgrywałem kodu :)
    A gdzie jest ten wspomniany bit blokowania zapisu?

    0
  • #6 08 Kwi 2013 17:56
    mickpr
    Poziom 39  

    Dahsheg napisał:
    A gdzie jest ten wspomniany bit blokowania zapisu?
    Nie mam tego procka -ale wciśnij w STLINK Utiity Ctrl-B
    Albo z menu Target->option bytes

    0
  • #7 08 Kwi 2013 21:46
    Dahsheg
    Poziom 9  

    Pamięć jest podzielona na obszary:
    0x00000000 do 0x00002A40
    0x08000000 do 0x08002A40

    Po drugim obszarze mogę pisać.
    We wspomnianym menu mogę włączać i wyłączać zabezpieczenie przed zapisem tylko dla drugiego obszaru, ponadto są do ustawienia bity:
    WDG_SW
    nRST_STOP
    nRWST_STDBY
    nBoot1
    VDDA_Monitor
    nSRAM_Parity
    Domyślnie wszystkie były włączone, próbowałem z wyłączonym ostatnim i z wyłączonymi wszystkimi. Ciągle to samo :(
    W menu znalazłem opcję Blank Check i po wywołaniu jej wyświetla się komunikat:
    "Cannot read flash memory beyond address 0x08010000. Flash memory below this address is blank."
    W opcji "Erase sectors" wyświetlone są tylko sektory od adresu 0x08000000.

    0
  • #8 09 Kwi 2013 08:36
    mickpr
    Poziom 39  

    W zależności od ustawienia Flash jest mapowana albo w adresy 0x00000000-0x00010000, albo w adres 0x08000000-0x08010000.
    Zobacz strona 35 datasheet
    http://www.st.com/st-web-ui/static/active/en/...e/technical/document/datasheet/DM00039193.pdf
    Nie wiem jak zachowuje się ST-LINK, ale MCU po reset ma zmapowany FLASH pod adres 0x00000000.
    Wygląda na to, że układ zachowuje się moim zdaniem dobrze.

    Dahsheg napisał:
    "Cannot read flash memory beyond address 0x08010000. Flash memory below this address is blank."

    I prawidłowo, bo masz tylko 64kB Flash.
    Czy na pewno dobrze wybrałeś MCU?

    0
  • #9 09 Kwi 2013 08:56
    Dahsheg
    Poziom 9  

    No ok, ale problem leży w tym, że nie mogę wpisać nic pod adres 0x00000000. Więc nie mogę wpisać nic do Flasha. STLink Utility samo odczytuje typ procesora po podłączeniu i wybiera go dobrze, z tym że pisze "Flash size: unknown"

    0
  • #10 09 Kwi 2013 09:19
    mickpr
    Poziom 39  

    Dahsheg napisał:
    No ok, ale problem leży w tym, że nie mogę wpisać nic pod adres 0x00000000
    Obszar od adresu 0x00000000 wcale nie musi być Flashem.
    Jest tam tylko - jeśli zostanie tam zmapowany.
    Standardowo jest pod adresem 0x08000000-0x08010000

    0
  • #11 09 Kwi 2013 09:27
    Dahsheg
    Poziom 9  

    Jak rozumiem, to pin Boot0 ustala czy tam jest Flash czy RAM. Na płytce Boot0 jest ściągnięty do masy i u mnie też jest tam masa. Więc jak mniemam powinien tam być właśnie Flash.

    0
  • #12 09 Kwi 2013 09:41
    mickpr
    Poziom 39  

    Muszę doprecyzować. Flash mapowany pod adres 0x0000 0000 (ze standardowego swojego miejsca - 0x08000000..0x08010000) jest widoczny JEDNOCZEŚNIE pod tymi dwoma lokalizacjami. Więc Flash powinieneś widzieć ZAWSZE w lokalizacji od adresu 0x08000000.

    0
  • #13 09 Kwi 2013 09:45
    Dahsheg
    Poziom 9  

    Ok, czyli jeśli umiem wpisać coś pod adres 0x08000000 a pod 0x00000000 już nie to znaczy, że pod adresem 0x00000000 nie jest widoczny Flash, a coś innego. Więc teraz pytanie jak przemapować pamięć?

    0
  • #14 09 Kwi 2013 10:07
    Freddie Chopin
    Specjalista - Mikrokontrolery

    Czy możesz po prostu całkowicie skasować układ, WŁĄCZNIE z option bytes? Sugestia taka pojawiła się już w czwartym poście, a Ty dalej debatujesz... Jeśli po tej operacji układ dalej nie będzie pracował prawidłowo, to znaczy że jest uszkodzony.

    4\/3!!

    0
  • #15 09 Kwi 2013 10:07
    mickpr
    Poziom 39  

    Tak jak napisałeś - Boot0 :)

    Czyli podsumujmy:
    -Programować flash możesz (w obszarze 0x0800000..0x08010000). Wyżej nie będzie działać, bo z typu MCU wynika, że ma on 64k Flash.
    -Boot0 ściągnięty do masy?
    -Program się nie uruchamia?

    W czym "kodujesz" (jakie środowisko IDE)?
    Piszesz, że IDE "nic nie mówi" - a kiedyś mówiło?
    Nie przestawiłeś typu MCU w IDE?

    0
  • #16 09 Kwi 2013 15:24
    Dahsheg
    Poziom 9  

    Programować Flash się da
    Boot0 jest ściągnięty do masy
    Programu nie da się wgrać.

    IDE to CooCox CoIDE. Wcześniej przy wgrywaniu programu pojawiał się komunikat o pomyślnym wyczyszczeniu pamięci, pomyślnym wgraniu i pomyślnym restarcie
    Teraz nie pojawia się nic, poza wywołaniem programu który ma to zrobić.
    I nie jest to wina IDE bo w STLink Utility jest podobnie. Tzn mogę odczytać pamięć (same F), mogę wyczyścić pamięć. Mogę ręcznie wpisać coś do Flasha, ale do pamięci widocznej pod adresem 0x00000000 już nie. Pojawia się komunikat "Error occured during memory writing", przy próbie wgrania pliku bin bądź hex (też przez STLink Utility) pojawia się "[0x0000000] Invalid address!".
    Mam jeszcze płytkę STM32F4discovery i na niej wszystko działa bez problemu. Tzn mogę wgrać program, wpisać coś ręcznie pod adres 0x00000000 etc.

    Pomiędzy pinem Boot0 a masą jest ok. 500ohm, tak jak na F4.

    Mogę też wywołać "Full chip erase", który nie zgłasza żadnego błędu, ale dalej jest bez zmian.

    Dodano po 3 [godziny] 16 [minuty]:

    Zauważyłem, że dane wpisane pod adres 0x08000000 są widoczne pod adresem 0x00000000, ale nie można ich zmienić pod tym adresem, jedynie pod 0x08000000.
    I niestety ciągle pojawia się błąd "[0x00000000]:Invalid address!".

    0
  • #17 09 Kwi 2013 23:55
    Dahsheg
    Poziom 9  

    Problem rozwiązany. Przynajmniej częściowo.
    Otóż przy programowaniu przez STLink Utility plikiem hex lub bin musiałem wpisać start address jako 0x08000000, w środowisku adres także zmienić na taki. W takiej konfiguracji da się programować i przez STLink Utility i przez CoIDE.
    Co najdziwniejsze, po zmianie w środowisku adresu z powrotem na 0x00000000 dalej mogę pomyślnie zaprogramować przez STLink Utility, ale przez CoIDE już nie.

    I powiedzmy że wszystko byłoby OK, gdyby nie to, że teraz straciłem możliwość debugowania.
    Jeśli włączę debugowanie program od razu sypie się na pliku starup_stm32f0xx.s
    Dokładnie na linii:

    Code:
    /* Copy the data segment initializers from flash to SRAM */ 
    
      movs r1, #0

    Jest to pierwsza instrukcja w pliku, wcześniej są deklaracje zmiennych.
    Opis błędu:
    Cytat:
    Execution is suspended because of error.
    continue
    Warning:
    Cannot insert breakpoint 2.
    Error accessing memory address 0x8001986: (undocumented errno -1).
    Cannot insert breakpoint 1.
    Error accessing memory address 0x800198a: (undocumented errno -1).


    Program wgrany do pamięci bez debugowania działa dobrze.
    W kodzie nic nie zmieniałem, a wcześniej debugowanie działało dobrze.

    0
  • #18 10 Kwi 2013 08:15
    mickpr
    Poziom 39  

    Dahsheg napisał:
    I powiedzmy że wszystko byłoby OK, gdyby nie to, że teraz straciłem możliwość debugowania.
    Jak masz ustawione debugowanie na zakładce Configuration->Link?
    Debug in Flash czy Debug in RAM ?

    0
  • #19 10 Kwi 2013 09:56
    Dahsheg
    Poziom 9  

    Flash. Kiedy ustawiam na RAM w zasadzie jest podobnie, poza tym, że środowisko chce jeszcze otworzyć jakiś plik, ale kończy to komunikatem "source not found".

    0
  • #20 10 Kwi 2013 10:32
    mickpr
    Poziom 39  

    Dahsheg napisał:
    Otóż przy programowaniu przez STLink Utility plikiem hex lub bin musiałem wpisać start address jako 0x08000000, w środowisku adres także zmienić na taki. W takiej konfiguracji da się programować i przez STLink Utility i przez CoIDE.
    Skoro problem z zapisem Flash jest "rozwiązany" i nie ma błędów wynikających ze "zużycia" to pozostaje problem z konfiguracją.

    0
  • #21 10 Kwi 2013 22:37
    Dahsheg
    Poziom 9  

    Problem rozwiązany.
    Wróciłem do wersji CoIDE 1.6.0 i do wersji gcc 4.6.3 i wszystko zaczęło na powrót działać.
    Wychodzi na to, że CoIDE bez mojej wiedzy się zaktualizowało.

    Tylko dziwi mnie to, że dalej nie mogę ręcznie nic wpisywać pod 0x00000000.

    0
  • #22 12 Kwi 2013 16:15
    mickpr
    Poziom 39  

    Dahsheg napisał:
    Wróciłem do wersji CoIDE 1.6.0
    A jaką miałeś poprzednio 1.7.0 czy 1.7.1 ?

    0
  • #23 14 Kwi 2013 19:28
    Dahsheg
    Poziom 9  

    1.7.1, musiał mi się dopiero co zaktualizować, bo kilka dni wcześniej bez problemu pisałem i wgrywałem kod.

    0
  • #24 06 Cze 2013 18:21
    LosRabinos
    Poziom 8  

    Witam

    Również mam problem z programowaniem pamięci Flash w środowisku CooCox CoIDE, dlatego podpiąłem się pod ten temat.

    Korzystam z zestawu edukacyjnego STM32F4 Discovery, a konfigurację programu CooCox przeprowadziłem zgodnie z artykułem ze strony:
    http://www.mikrokontroler.pl/content/coocox-c...m32f4discovery-%E2%80%93-jak-zacz%C4%85%C4%87

    Po zainstalowaniu wersji programu CooCox o numerze 1.5.1, toolchain'a gcc-arm-none-eabi-4_7-2013q1-20130313-win32.exe oraz sterowników do programatora ST-LINK/V2, dokonałem budowy projektu. Wynik był taki sam jak w powyższym artykule ze strony mikrokontroler.pl, czyli wszystko ok.
    Problem pojawił się niestety w momencie próby wgrania programu do pamięci flash za pomocą przycisku "Download Code to Flash". Po tej operacji w konsoli w dolnej części programu CooCox pojawił mi się komunikat:
    C:\CooCox\CoIDE>"C:/CooCox/CoIDE/bin\coflash.exe" program STM32F407VG "C:/CooCox/CoIDE/workspace/Proj1\Debug\bin\Proj1.bin" --adapter-name=ST-Link --port=SWD --adapter-clk=1000000 --erase=affected --driver="C:/CooCox/CoIDE/flash/STM32F4xx_1024.elf"
    Erase: Done
    Program: Done
    Verify: Done

    Program wykonuje się co prawda poprawnie, czyli dwie diody mrugają na przemian, ale po odłączeniu przewodu USB od zestawu i ponownym podłączeniu diody nie mrugają wcale.
    Pierwsza myśl jaka mi przyszła do głowy, to taka, że program wgrywany jest do pamięci RAM zamiast FLASH. Sprawdziłem ustawienia konfiguracyjne w programie CooCox i wszystko wygląda ok. (zdjęcie poniżej).
    STM32F0 - Zablokowana pamięć Flash

    Gdy taki sam program wgrywam za pomocą programu Attolic True Studio, to program wykonuje się nawet po ponownym uruchomieniu układu, czyli na to wygląda, że program trafia do pamięci FLASH.

    Czy takie zachowanie układu z wykorzystaniem środowiska CooCox to wina tego, że program wgrywany jest do pamięci RAM zamiast FLASH, czy może jakiś inny powód?

    Bardzo proszę o jakiekolwiek wskazówki.
    Pozdrawiam

    0