STM32F103 - Zapis do FLASHa nie działa przy optymalizacji -Os. Co robić?

Już od wielu lat znam problem ale nigdy nie chciało mi się do niego przysiąść. Czyli lenistwo poziom expert.
Do obsługi FLASHa używam nieznacznie przerobionych kodów autorstwa w123456xy (nie z elektrody, tylko gdzieś w internecie znalazłem).
I problem taki: Dam optymalizację -O0, działa. Dam -Os, nie działa.
Do tej pory radziłem sobie po prostu pozostawiając optymalizację -O0.
Ale najwyższa pora coś z tym zrobić.
Kod raczej prosty:

Porównałem operacje i ich kolejność z datasheetem, i się zgadzają.
I moja funkcja:

Niedziałanie dla -Os w ogólności polega na tym że w pamięci ciągle znajdują się wartości 0xFF.
Dzisiaj porobiłem trochę testów i wnioski są takie:
1. Samo kasowanie pamięci jednak działa. Jak pamięć zawiera coś innego niż 0xFF to wywołanie funkcji Zapisz_EEPROM zmienia te wartości na 0xFF (niezależnie od tego co podam w tablicy TAB (dla -O0 zapisuje we FLASHu wartości tej tablicy)).
2. Zmienianie Timeoutów nic nie zmienia w działaniu.
3. Funkcja FLASH_WaitForLastOperation zwraca wartość 4, czyli PGERR: Programming error.
I tu ciekawostka, zwraca to nawet dla optymalizacji -O0 (mimo że zapis wtedy działa), oraz również dla kasowania pamięci. I to mnie trochę dziwi. Bo chyba powinno zwracać taką wartość tylko dla programowania? Przy kasowaniu oczywiste jest że wartość wejściowa może być inna niż 0xFF (bo dopiero kasujemy do wartości 0xFF) więc jaki sens ma zwracanie błędu w takim przypadku?
4. Widząc błąd powyżej, dodałem kasowanie flagi PGERR przed wywołaniami funkcji FLASH_WaitForLastOperation (myślałem że po prostu flaga PGERR pamięta jakiś błąd z wcześniejszych operacji). Ale nic się w działaniu nie zmieniło. Ciągle mam 4-krotnie zwracaną wartość równą 4.
4-krotnie czyli:
- przed wykasowaniem strony (po sprawdzeniu czy FLASH nie jest zajęty jakąś operacją)
- po wykasowaniu strony (po oczekiwaniu na zakończenie kasowania strony)
- przed zapisem strony (po sprawdzeniu czy FLASH nie jest zajęty jakąś operacją)
- po zapisaniu (albo i nie zapisaniu) strony (po oczekiwaniu na zakończenie zapisu ostatniej wartości na stronę)

Posprawdzałem w plikach lss czym się różnią te dwa kody. Różnice oczywiście widzę, ale nie wiem jaki wpływ na działanie może to mieć.
Np. zapis do FLASH->KEYR:
Wersja -O0:

Wersja -Os:


I nie wiem. Spodziewał bym się np. że zapis musi być w całości 32-bitowy (czyli że procek nie akceptuje dostępów 8 czy 16-bitowych do tego rejestru). Ale nic na ten temat nie znalazłem w datasheecie czy też w manualu STM32F100xx
value line Flash programming. Ale tu akurat w obu wersjach zapis samego rejestru jest taki sam (instrukcja str r2, [r3, #4]).
To może jakieś Timingi? Też nic nie piszą w datasheecie (że np. zapis musi być nieprzerywany przerwaniami, albo np. następować w gwarantowanym odstępie np. 4 cykli zegarowych tak jak to jest np. w przypadku rejestrów układu RTC). No nic nie pisze.

I tym sposobem pomysły mi się skończyły. Więc pytam na forum.
Ktoś coś wie na ten temat?
Są jakieś wymagania co do dostępów do rejestrów FLASH->KEYR i innych?

PS. Oczywiście pamięć FLASH jest w całości odblokowana.

Freddie Chopin napisał:

atom1477 napisał:

3. Funkcja FLASH_WaitForLastOperation zwraca wartość 4, czyli PGERR: Programming error.

Raczej wartość 4 czyli FLASH_COMPLETE.

Heh, faktycznie.
Ale ciągle jest to dziwne. Bo zwraca to i dla -O0 i dla -0s. A dla -Os zapis przecież nie działa.
W takim razie posprawdzałem co zwraca rejestr FLASH->SR.
W obu przypadkach zwraca 4-krotnie wartość 32 (czyli flagę EOP: End of operation, i żadnych błędów).
Trochę to utrudnia debugowanie skoro nie zwraca to żadnych błędów.

Makra takie:

Cytat:

/* Flash Control Register bits */
#define CR_PG_Set ((uint32_t)0x00000001)
#define CR_PG_Reset ((uint32_t)0x00001FFE)
#define CR_PER_Set ((uint32_t)0x00000002)
#define CR_PER_Reset ((uint32_t)0x00001FFD)
#define CR_MER_Set ((uint32_t)0x00000004)
#define CR_MER_Reset ((uint32_t)0x00001FFB)
#define CR_OPTPG_Set ((uint32_t)0x00000010)
#define CR_OPTPG_Reset ((uint32_t)0x00001FEF)
#define CR_OPTER_Set ((uint32_t)0x00000020)
#define CR_OPTER_Reset ((uint32_t)0x00001FDF)
#define CR_STRT_Set ((uint32_t)0x00000040)
#define CR_LOCK_Set ((uint32_t)0x00000080)

Dodanie volatile nic nie zmienia.
Ale właśnie zauważyłem inną dziwną rzecz.
Tablicę TAB wypełniałem danymi z UARTa tylko w komórkach od 0 do 7 (a cała tablica ma 2048 B):

A w innym miejscu odsyłałem na UARTa dane z FLASHa:

I gdy teraz zamieniłem ostatnie 4 bajty na ostatnie z tablicy (2044...2047):

to zaczęło działać.
Czyli tak jakby problemem nie były funkcje do zapisu FLASHa tylko coś z obsługą tablicy TAB (jakby nie zapisywało w niej wartości albo nie brało jej pod uwagę do zapisu FLASHA).
Ale sprawdziłem w plikach map i są mniej więcej zgodne (jedynie dla tablicy wypełnianej 0...3 i 2044...2047 (zamiast 0...7) adresy w RAMie się przesuwają o 8 B w górę, i rozmiar pliku wynikowego HEX się zwiększa o 16B).


Jedyna zmiana to zmiana strb na strb.w oraz inne adresy tych 4 ostatnich bajtów z tablicy.
Co to za cuda się tu dzieją?
Freddie Chopin: mógł byś zamieścić ten Twój "bardzo podobny ale bez udziwnień" kod?

W załącznikach mój projekt.

Elektro_guru:
1. Wytrzymałość FLASHa w STM32F1xx wynosi 10 tyś a nie 1 tyś.
2. Zapisuję całe 2048 B (wcześniej było 4096 ale zmieniłem na 2048) bo się inaczej nie da (tzn. przed zapisem i tak muszę skasować całą stronę która ma 2048 B).
3. Wykorzystuję tylko kilka bajtów bo robię testy zapisu. Do testów wystarczy (na razie) sprawdzać czy się zapisało kilka bajtów.
Docelowo potrzebuję zapisywać około 8 kB danych.

Wyrównywanie buforów to efekt poszukiwań problemów z zapisem.

Oczywiście znam tą notę.

A co do zapisu to chyba odkryłem problem.
Chodziło to:

Cytat:

*(volatile unsigned short*)Address = Data;

Przy czym coś jeszcze w kodzie musiałem zmienić bo wcześniej dodanie volatile nie dawało efektu.
W każdym razie teraz działa.
Zmienia się kolejność 2 instrukcji.
Jest:

albo:

Nie wiem dlaczego to miało by mieć znaczenie skoro te instrukcje operują na innych rejestrach.
Pomiędzy tymi dwoma instrukcjami nic już nie ma innych instrukcji. Jest za to dużo opisu tekstowego (treści kodu który rzekomo w danym miejscu jest kompilowany) który też na maxa zmienia kolejność.
Swoją drogą ten opis dla optymalizacji -Os to totalny burdel. Kilkukrotnie powtarzane są te same fragmenty kodu. Nic z tego opisu nie można wywnioskować.
Dla -O0 jest normalnie. Po prostu linia kodu, kilka linii assemblera, znowu linia kodu, kilka linii assemblera.
Oczywiście wiem że dla -Os tak się nie da bo kod jest mocno upychany. Ale w takim wypadku opisów powinno być raczej mniej a nie więcej. Ale nieważne.
Zastanawia mnie jeszcze dlaczego w ogóle nie działa mi kod podesłany przez Freddie Chopin-a (nie mogę go tutaj opublikować). Sprawdzę to później debuggerem jak uda mi się go uruchomić.

Sprawdziłem też dla docelowego kodu (ten z tego wątku to inny kod, taki na maxa uproszczony jedynie to testów zapisu).
W docelowym kodzie kolejność zmieniają 4 instrukcje (również operujące na innych rejestrach), a do tego dla -Os wywalana jest instrukcja:


Czyli póki co chyba to volatile załatwia sprawę. Posprawdzam jeszcze dla innych kodów gdzie mam zapis FLASHa.

Freddie Chopin napisał:

Szukasz w jakichś szczegółach typu kolejność linii assemblera, a one kompletnie nie mają znaczenia...

Żeby wiedzieć że nie mają znaczenia to trzeba to sprawdzić. Dlatego sprawdziłem.
Czy wiedziałbyś że nie mają znaczenia gdybym napisał że kody assemblerowe się różnią ale nie napisał czym się różnią (nie napisał że różnią się tylko kolejnością)?

Freddie Chopin napisał:

Kod który Ci podesłałem działa "od lat" na dowolnym poziomie optymalizacji na różnych układach - z drobnymi modyfikacjami działa w zasadzie dla wszystkich rodzajów STM32 (w STM32F4 są nieco inne bity w rejestrach, ale różnice są kosmetyczne). Jeśli u Ciebie nie działa, to:
- masz uszkodzony mikrokontroler,
- źle go używasz.

Uproszczę zaraz mój kod i jeszcze raz to sprawdzę.

Cytat:

Raczej "przypudrowaniem problemu", a nie żadnym "rozwiązaniem" (;

No to zależy od tego co jest problemem.

No właśnie tak chcę zrobić. Kod który tylko ma zapisać jednorazowo FLASH. A potem sobie go odczytam już za pomocą FlashMagica.
Ale po kolei. Za dużo na raz. Jeszcze próbuję uruchomić Debugger.

Dzięki za chęć przetestowania tego u siebie.
Ale mam niespodziankę: można wymusić niedziałanie na tym kodzie.
Wiem że to dziwne i sam tego nie rozumiem, ale program zachowuje się tak jak pisałem: czyli wersja bez volatile nie zapisuje gdy tablica ALGO_TAB jest wypełniana jedynie na początku.
Z volatile zapisuje zawsze.
Programy z volatile i bez volatile różnią się tylko dwoma instrukcjami.
Wiem że to dziwnie brzmi ale sprawdź u siebie:
FLASH_ProgramHalfWord:

main:

Wywaliłem EraseSector tam u góry w mainie, gdyż EraseSector jest wywoływane wewnątrz funkcji Zapisz_EEPROM.

Efekty u mnie. Rożnica w kodach w plikach lss (na czerwono jeden plik, na zielono drugi, na szaro gdy oba pliki mają w danym miejscu zgodną treść):

Czyli widać że w czerwonym najpierw jest strh a potem movs, a w zielonym najpierw movs a potem strh.

Pliki map się w głównej części nie różnią. Różnica jest tylko w tym fragmencie:

I wyniki z terminala:
Z volatile:

Bez volatile:

(wartości to 0xFF)

Wiem że to dziwne, ale proszę żeby QuadMan to sprawdził u siebie zanim jakieś wnioski ktoś będzie wyciągał.
W załączniku wszystkie ważniejsze pliki z kompilacji moim kompilatorem dla obu wersji.

PS. I jeszcze jedną rzecz wyjaśnię. W plikach lss nie szukam błędów kompilatora.
Szukam tam efektów kompilacji, bo na ich podstawie można znaleźć błędy w swoim własnym kodzie (jak efekty kompilacji są inne niż by się chciało, to znak że coś w naszym kodzie jest źle).

PS2. I oczywiście kasowanie działa w obu przypadkach. W końcu w funkcji kasującej nic się nie zmienia.

A no racja, zapomniałem że po drodze są jeszcze te dwie instrukcje (str i orr).
Zastanawiam się tylko jaki cel ma kompilator w przestawieniu tych instrukcji. Nie zyskuje na tym miejsca we FLASHu.
Czy może chodzić o opóźnienie w dostępie do szyny jakie powodowałoby umieszczenie instrukcji str i ldr bezpośrednio obok siebie?

W każdym razie problem rozwiązany.
Jeszcze raz wielkie dzięki za pomoc.

Ale przy okazji mam jeszcze jedno inne pytanie.
Jak zadeklarować tablicę we FLASHu i ją od razu zainicjalizować?
Chodzi mi o to żeby wartości trafiły do pliku HEX na etapie kompilacji.
Czyli żeby programując procesor w tym symulowanym EEPROMie już siedziały domyślne ustawienia.
Myślałem że wystarczy coś takiego:

Cytat:

volatile uint8_t TABLICA_EEPROM[8] __attribute__ ((section(".eeprom_mem"))) __attribute__ ((aligned (32))) =
{
10, 2, 4, 6, 10, 2, 4, 6
};

Ale to nie działa (nic się nie zmienia w kodzie wynikowym).

Sekcję mam zadeklarowaną tak:


Czy może chodzi o NOLOAD?

Freddie Chopin napisał:

nie żadne "volatile", tylko po prostu "const".

Zmieniłem.

Freddie Chopin napisał:

Swoją drogą to nie wiem czy atrybuty można łączyć tak jak pokazałeś, na pewno można je łączyć po prostu po przecinku wewnątrz nawiasów.

Kiedyś o to pytałem i wyszło że można i tak. Choć krócej będzie po przecinkach. Pozamieniam.

Freddie Chopin napisał:

Twoja tablica nie jest wgrywana, bo dałeś noload - to chyba powinno być oczywiste [;

Było oczywiste dopóki nie przeczytałem opisu atrybutu NOLOAD (tutaj).
Jest dla mnie tak niejasny że musiałem zapytać (to "at run time" mnie zmyliło).
Dzięki.

Freddie Chopin napisał:

BTW - zamiast samego "> eeprom" na końcu sekcji proponuję naprawdę " > eeprom AT > eeprom".

Też poprawiłem.

Po tych 3 zmianach (const, NOLOAD i eeprom AT) czyli:


niestety nic się nie zmieniło.
Oczywiście tą tablicę w programie używam, więc kompilacja -Os nie powinna jej wywalać. Ale dla pewności sprawdziłem też dla -O0 i wtedy też nic się nie zmienia.

Nie ma danych pod adresem tej tablicy w pliku wynikowym HEX (w sensie że plik HEX w ogóle nie zawiera takiego adresu).
W pliku map tablica się pojawia (tzn. jest po prostu określony jej adres).

Dziwne by było żeby wgrywał skoro plik tego nie zawiera ani nawet w ogóle się nie zmienia
No ale sprawdziłem. Nie wgrywa.

Przy okazji tworzenia tego minimalnego projektu rozwiązałem problem.
Problemem był niejawny dostęp do tej tablicy.
Zamiast adresu jako liczby dałem (uint32_t)ALGO_TAB_EEPROM. I teraz się pojawiła w pliku HEX.
Dziwię się tylko że nie inicjalizowało tej tablicy dla optymalizacji -O0.

No to znowu mam problem. W innych projektach gdzie chciałem zastosować te wszystkie poprawki.
Po zmianie volatile na const (wcześniej też zmieniłem NOLOAD i eeprom AT):

wywala mi błąd:

Z const, ale bez inicjalizacji wartością 10, błędu nie ma.

W załączniku uproszczony projekt. Zauważyłem że problem występuje gdy pierwsza tablica jest typu volatile i próbuję ją inicjalizować.
Albo gdy jest const ale bez inicjaliacji.
Gdy w projekcie jest tylko jedna tablica to problem nie występuje niezależnie od sposobu deklaracji tablicy (niezależnie czy jest const czy volatile i niezależnie czy ją inicjalizuję czy nie).