C++ ośla łączka

tu masz pomysl z druga funkcją - ale uprzedzam, ze kompilator z linkerem moga je inaczej rozmieszczac

J.

Moim zdaniem zbyt optymistycznie do tego podchodzisz. Jak flash będzie nie do końca zaprogramowany (bo zniknęło napięcie w trakcie programowania) to może w większości przypadków dobrze się odczytywać ale czasem źle. Taki błąd może być bardzo trudny do znalezienia. Kiedyś w naszym emulatorze EPROMów mieliśmy taki błąd, że średnio statystycznie raz na 3 miliony odczytów jakiś jeden bit potrafił mu się przekłamać. Statystykę zebraliśmy programem czytającym w koło znaną zawartość. Miałem wtedy tylko jednokanałowy, analogowy oscyloskop, który sobie sam zrobiłem (pasmo 5MHz) - żadnej szansy wyłapania tego momentu. To wszystko było jeszcze THT - się okazało, że jakiś kondensator trzeba było bliżej nóg zasilających przenieść i problem zniknął. P.G.

W dniu 2023-02-17 o 02:28, JDX pisze:

Nie mam pojęcia czego używamy. To nie na temat - wiem, że teraz brat przełącza się często między dwoma komputerami. Na jednym Win7 i jakaś stara wersja środowiska (kojarzy mi się, ze mówił, że czwarta) w której jest ileś rzeczy, które mu są potrzebne i drugi Win10 na którym nowa wersja (piata?) środowiska (bo wymaga WIN10) w której jest z kolei coś innego co jest mu potrzebne, ale brakuje tego czegoś, co było w starym. Nie umiem dokładniej bo jak mi miesiąc czy dwa temu o tym mówił to nie starałem się zapamiętać o co biega.

Brat mówił, że większość rozwiązań opiera się na wymuszaniu na linkerze jakichś działań, ale nie chce się w to bawić. Na dziś przyjął, że napisze tę funkcję (chyba 10 bajtów) w assemblerze i wtedy będzie dokładnie znał jej rozmiar. Widział też jakieś rozwiązania polegające na tym, że kawałek kodu ląduje na stałe w RAMie. Tylko jakoś tak (nie wiem czy uzasadnienie) bardziej wierzę, że po 10 latach procedura we flashu nadal jest jaka była, a czy jakieś zakłócenie nie naruszy w tym czasie RAMu...

To nasze (a właściwie mojego brata) pierwsze podejście do więcej niż

Brat już wyszedł z pracy, a do poniedziałku zapomnę pytania. Jeśli on teraz jest (99%) w PG22 to może to być tylko ten pdf:

W dniu 2023-02-17 o 20:42, J.F pisze:

Przesłałem mu ten link - zajrzy sobie w poniedziałek. W tym poprzednim, który podałeś (jeśli czegoś nie pomieszałem) to brat powiedział, że to właściwie o 51-ce, ale spodobała mu się tam metoda uzyskania z kompilatora funkcji w assemblerze. Nie wiem czym to się różni od tego co on normalnie stosuje, bo wiem, że zagląda jak coś się kompiluje, ale widocznie czymś się różni.

W każdym razie na razie zdecydował, że wpisuje te parę bajtów w assemblerze.

Ja mam na głowie kilka szybkich projektów płytek. Na razie lista do zrobienia 'na wczoraj' narasta szybciej niż się wygrzebuję z poprzednich.

Strasznie głupio projektować już kolejne płytki na nieznanym sobie procesorze, gdy poprzednich nie mieliśmy jeszcze jak sprawdzić. P.G.

heby snipped-for-privacy@poczta.onet.pl> napisał(a):

Może być różnie, ale np. konieczność zaczynania procedury od początku. To taki komunikat: daj mi skończyć ten update bo inaczej będziesz musiał wszystko wyklikiwać od początku. Ewentualnie jeśli jak w Windowsie update jest przy wyłączaniu: to zamykanie trwa dłużej niż zwykle ze względu na aktualizację, więc wykaż się większą cierpliwością.

Piotr Gałka snipped-for-privacy@cutthismicromade.pl napisał(a):

Dlaczego chcecie sami kopiować tę funkcję? Czy skonfigurowanie odpowiedniej sekcji w skrypcie linkera nie wchodzi w grę? Przykładowo funkcja do zapisu Flash znadująca się w RAM-ie jest w bibliotekach ST:

__RAM_FUNC HAL_FLASHEx_HalfPageProgram(uint32_t Address, uint32_t* pBuffer);

Makro __RAM_FUNC zdefiniowane jest tak:

#define __RAM_FUNC HAL_StatusTypeDef __attribute__((section(".RamFunc")))

Czyli funkcja HAL_FLASHEx_HalfPageProgram jest oznaczona atrybutem umieszczającym ją w sekcji .RamFunc. Ta z kolei w skrypcie linkera jest umieszczana w sekcji .data:

.data : { . = ALIGN(4); __data_init_start = LOADADDR(.data); PROVIDE(__data_init_start = __data_init_start); __data_start = .; PROVIDE(__data_start = __data_start);

. = ALIGN(4); *(.data .data.* .gnu.linkonce.d.* .RamFunc)

. = ALIGN(4); __data_end = .; PROVIDE(__data_end = __data_end); } > ram AT > rom

Jest bardzo łatwy. Przeciez nie zapomniałeś dodać sum kontrolnych a porządne urządzenie zazwyczaj sprawdzi swoje sumy kontrolne na starcie. Wiadomo, że nastapiło przerwanie programowania. Jedyny przypadek, kiedy to nie zadziała to chyba programowanie tego samego wsadu ponownie.

I jesteś pewny, że to statystycznie istotny przypadek? Mowa o tysiącach źle napisanych procedur upgrade firmware pisanych przez kiepskich programistów, a nie o przypadku jeden na miliony. Z resztą przy takiej statystyce to może być najzwyczajniej pamięc flash z marginalnym bitem, co wcale nie jest takie niemożliwe. Mogło go stuknąc nawet promieniowanie jonizujące, przypadki nie są wykluczone, ale szacujemy ryzyko i się nimi nie przejmujemy w typowych zastosowaniach.

I czy aby na pewno miało to związek z błedami programowania czy bardziej z tym kondensatorem?

Z ciekawostek, to równoległe pamięci flash mogły się "gorzej" programować, jesli impuls kasujący miał zła długość (nie pamiętam czy za długi czy za krótki, to było wieki temu). Znalezione przypadkiem przez kolegę który osiwiał przy jakimś systemie uC w latach 90. Tak że dam wiarę, że coś może pójść nie tak. Tylko czy aby na pewno to problem z firmware? Urządzenie z update firmware musi być sensownie zaprojektowane aby zaniki zasilania nie były możliwe w połowie programowania strony i to nie wydaje się jakoś super trudne do wymyślenia.

Nie radze próbować. Zaden system plików nie lubi, jak mu wyłączyc nagle zasilanie, SSD nie lubi potrójnie, a i taka czesciowa aktualizacja może byc zgubna.

J.

Tak, są 32 sprzętowe spinlocki w bloku SIO – jakiś mechanizm synchronizacji dać musieli bo inaczej wielordzeniowość tego MCU byłaby mało użyteczna. Ale IMO jest to rozwiązanie z kategorii sztuczek – nie jest to „standardowa” para instrukcji typu load-linked/store-conditional, której używają współczesne (i nie tylko) mejnstrimowe RISC-i.

Co to znaczy "nie do końca"? Z flash jest jak z ciążą, nie można być w niej trochę. Jeśli crc całości (po wygraniu) się zgadza to nie przewiduje się by to jeszcze poprawiać. Jeśli zostało przerwane to flashuje się ponownie, ale to chyba oczywista oczywistość.

Nie ma takiej potrzeby, wystarczy że wsadzisz funkcję do swojej własnej sekcji (a ta sekcja może wylądować wewnątrz np. data), dodasz etykiety na początku i końcu sekcji w skrypcie linkera. Potem takie etykiety mogą być widoczne w kodzie C jako dowolna zmienna extern, której adres można pobrać i z różnicy wyliczyć długość.

Zbych snipped-for-privacy@somewhere.com napisał(a):

Pozwolę sobie podlinkować przykład:

Nie podoba mi się w tym przykładzie poleganie na kolejności umieszczania funkcji w pamięci (flash_function i flash_function_end). Zdecydowanie lepiej wygląda to:

W dniu 2023-02-17 o 23:06, Grzegorz Niemirowski pisze:

W którejś wiadomości już pisałem, że mam takie, może nie całkiem racjonalne podejrzenie, że wpisana do RAMu wartość po 20 latach może ulec jakiemuś zakłóceniu i nie wróci sama do stanu prawidłowego a dana z flasha jak kiedyś przy jednym odczycie zostanie zakłócona to można liczyć, że przy kolejnym już się odczyta prawidłowo. P.G.

Myślałem o tym jak pisałem, ale już nie chciało mi się rozwijać szczegółów. W ramach praw Murphy'ego przyjmuję, że takie zniknięcie napięcia zdarzy się wtedy, kiedy wywoła najwięcej problemów. Jak to się zdarzy przy zapisywaniu ostatniej strony programu to wtedy może być tak, że przy weryfikacji odczyta się dobrze więc program zostanie uruchomiony, a potem czasem dobrze a czasem źle powodując jakieś trudne do przewidzenia zachowania.

W przypadku emulatora EPROMów jak najbardziej - raz na 3s program idzie w maliny (51-ka z kwarcem 12MHz).

A czy ja twierdziłem, że to miało jakikolwiek związek z błędami programowania. To było na temat, że jak odczyt pamięci prawie zawsze jest OK, a czasem błędny to może być problem (a tak się chyba może zachować flash, gdy programowanie zostało przerwane wyłączeniem zasilania).

Mam wrażenie, że w tym miejscu już zapomniałeś, że cała dotychczasowa Twoja wypowiedź kwestionuje moje stwierdzenie uznające za zbyt optymistyczne podejście "A co to za problem? Jak się przerwie programowanie z jakiekolwiek powodu to bootloader....". P.G.

To wina w końcu emulatora czy epromu? Bo się pogubuiłem do czego to dygresja.

Ale na to jest CRC. Trochę z tym problemem "źle działajacych flash bo przerwali programowanie w połowie" przesadzamy. ja rozumiem, że mogło się coś zaprogramować marginalnie źle, ale to znaczy, że zapewne za szybko zanikło zasilanie, zanim flash zakończył co miał zakończyć.

a) stosujac CRC zapewniasz sobie ochornę przed przerwanym w połowie programowaniem. Rola programisty. b) stosujac zasilanie flasha na ułamek sekundy dłużej niż cpu (z solidnym wykrywaniem zaniku) zapewniasz sobie że to co się zdążyło zaprogramować powinno być poprawne. Rola hardwareowca.

Jakei jeszcze problemy można mieć ze zwykłym update firmware, poza zwykłym pechem promieniowania kosmicznego?

W dniu 2023-02-19 o 12:29, Marek pisze:

Ja zakładam, że jeśli programowanie flasha zostanie nagle przerwane to znaczy że gdzieś tam za mało elektronów mogło zostać wstrzyknięte i odczyt niektórych bitów może być niepewny (np. większość razy prawidłowy, ale sporadycznie błędny). Odczyt bitu z flasha na pewnym tam poziomie jest działaniem analogowym a nie cyfrowym - czy poziom ładunku jest powyżej czy poniżej pewnego poziomu. Bit nie ma trzeciej wartości informującej, że może 0 a może 1 aby zaalarmować, że jest niepewny. Jak sprawdzany poziom jest w pobliżu progu to różne czynniki zewnętrzne mogą wpływać na to co zostanie za danym razem odczytane. Dopuszczenie do takiej sytuacji wydaje mi się błędem. Procesor po resecie nie musi wiedzieć, że ostatnią rzeczą jaką robił było akurat wystartowanie procesu programowania strony flasha więc nie wie, że musi jeszcze raz flashować. Sprawdzi crc - wyjdzie ok, bo akurat ten odczyt miał szczęście być prawidłowy i błędnie przyjmie, że jest ok. Jak pobiera upgrade to może mieć gdzieś info, że zaczął, ale nie skończył więc trzeba powtórzyć, ale ja zakładam używanie flasha też do danych. Zamiast otaczać każdy zapis zapisaniem, gdzieś w EEPROMie (co też można zacząć kwestionować) informacji, że rozpoczynam zapis strony

Jak EPROM jest zastąpiony emulatorem to EPROMu jako takiego nie ma - nie może być jego wina.

Od samego początku o tym jest rozmowa. Ktoś napisał (nie chce mi się sprawdzać kto), że można się nie przejmować tym, że programowanie zostanie nagle przerwane. A ja po prostu uważam, że jak rozpocznie się programowanie strony flasha to należy zapewnić zasilanie aż do jego dokończenia bo uważam, że po takim nie dokończonym programowaniu może powstać sytuacja w której crc czasem pokaże że jest ok, mimo, że nie zawsze odczyt daje te same dane.

Może źle zrozumiałem wypowiedź "A co to za problem..." jako sugerującą, że zapewnienie zasilania flasha na czas programowania nie jest niezbędne. P.G.