On Fri, 17 Feb 2023 20:44:12 +0100, Piotr
Gałka<p...@c...pl> wrote:
> 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.

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ść.

--
Marek

do góry

On 17.02.2023 20:42, J.F wrote:

> Gdzies w raporcie linkera powinna byc dlugosc kodu funkcji.
> Ale to troche niewygodne tak sprawdzac za kazdą kompilacją.
> No moze nie za kazdą - po grubszej zmianie.

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ść.

do góry

Zbych <z...@s...com> napisał(a):
> 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ść.

Pozwolę sobie podlinkować przykład:
https://stackoverflow.com/questions/72089507/apm32-c
-copy-execute-function-in-ram

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 20.02.2023 13:57, Grzegorz Niemirowski wrote:
> Zbych <z...@s...com> napisał(a):
>> 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ść.
>
> Pozwolę sobie podlinkować przykład:
> https://stackoverflow.com/questions/72089507/apm32-c
-copy-execute-function-in-ram

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:
https://stackoverflow.com/questions/4156585/how-to-g
et-the-length-of-a-function-in-bytes

do góry

W dniu 2023-02-17 o 23:06, Grzegorz Niemirowski pisze:
> Piotr Gałka <p...@c...pl> napisał(a):
>> No i w czasie tego przygotowywania się natknął się na info, że:
>> Jak się chce modyfikować flash to kawałek funkcji ma być wykonywany z
>> RAMu. To co ma być w RAMie kompiluje się bratu do 10 czy 12 bajtów. Na
>> zapas przekopiowywał do RAMu 40 bajtów, ale chciał to zrobić
>> dokładnie, bo kto wie, czy kiedyś jakaś kolejna wersja kompilatora
>> czegoś tam nie wrzuci i zrobi się ponad 40 bajtów.
>> On jest na etapie, że kiedyś wszystko pisał wyłącznie w asm, a obecnie
>> stara się wszystko napisać w C - że niby bardziej przenośne.
>> Ale nie udało mu się znaleźć metody policzenia tego "sizeof(funkcja)"
>> więc mówił mi dziś, że ten kawałek zostawi w asm aby nie mogło być
>> żadnych niespodzianek.
>
> 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:

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.

do góry

W dniu 2023-02-17 o 23:58, heby pisze:
> On 17/02/2023 20:44, Piotr Gałka wrote:
>>> A co to za problem? Jak się przerwie programowanie z jakiekolwiek
>>> powodu to bootloader zaprogramuje ponownie po resecie.
>> 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.
>
> 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.

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.

>> 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ć.
>
> I jesteś pewny, że to statystycznie istotny przypadek?

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

>> 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ął.
>
> I czy aby na pewno miało to związek z błedami programowania czy bardziej
> z tym kondensatorem?

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).

> Urządzenie z update firmware musi być sensownie zaprojektowane
> aby zaniki zasilania nie były możliwe w połowie programowania strony

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.

do góry

On 22/02/2023 13:02, Piotr Gałka wrote:
>>> 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ć.
>> I jesteś pewny, że to statystycznie istotny przypadek?
> W przypadku emulatora EPROMów jak najbardziej - raz na 3s program idzie
> w maliny (51-ka z kwarcem 12MHz).

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

> 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).

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ć.

>> Urządzenie z update firmware musi być sensownie zaprojektowane aby
>> zaniki zasilania nie były możliwe w połowie programowania strony
> 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....".

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?

do góry

W dniu 2023-02-19 o 12:29, Marek pisze:
> On Fri, 17 Feb 2023 20:44:12 +0100, Piotr
> Gałka<p...@c...pl> wrote:
>> 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.
>
> 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ść.

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
100 flasha i jak po resecie jest taka informacja to wie, że strona
wymaga naprawy uważam, że lepiej zagwarantować dokończenie każdego
rozpoczętego zapisu.
A jak są procesory bez EEPROMu w których robi się emulację EEPROMu we
flashu to w ogóle nie wiem jak miałby sobie zapisywać informację, że
właśnie jest w trakcie programowania flasha, aby po resecie miał szansę
wiedzieć, że flash może być niepewny.
P.G.

do góry

W dniu 2023-02-22 o 13:16, heby pisze:
> On 22/02/2023 13:02, Piotr Gałka wrote:
>>>> 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ć.
>>> I jesteś pewny, że to statystycznie istotny przypadek?
>> W przypadku emulatora EPROMów jak najbardziej - raz na 3s program
>> idzie w maliny (51-ka z kwarcem 12MHz).
>
> To wina w końcu emulatora czy epromu? Bo się pogubuiłem do czego to
> dygresja.

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

>
>> 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).
>
> 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ć.

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.

>
>>> Urządzenie z update firmware musi być sensownie zaprojektowane aby
>>> zaniki zasilania nie były możliwe w połowie programowania strony
>> 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....".
>
> 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.

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.

do góry

Piotr Gałka <p...@c...pl> napisał(a):
> 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.

Czyli chcesz mieć koniecznie własną funkcję kopiującą żeby móc to kopiowanie
ponawiać w trakcie pracy urządzenia zamiast wykonywać je tylko na starcie?

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry