On Fri, 17 Feb 2023 20:30:22 +0100, Piotr Gałka wrote:
> W dniu 2023-02-16 o 19:22, Marek pisze:
>> On Thu, 16 Feb 2023 13:20:42 +0100, Piotr
>> Gałka<p...@c...pl> wrote:
>> Ciekawe. Nie wiem jak w arm ale w mips setki tysięcy razy programowałem
>> flash z kodu będącym w innej stronie niż strona programująca i nigdy nie
>> miałem z tym problemu.
>>
>
> Z tego co brat mówi, to dotychczas w AtXmega (dawniej w Atmega)
> dokładnie tak robił - programuje flash z kodu w innej stronie flasha.
>
> Ale to na pewno nie jest tylko nasz wymysł. Brat znalazł wczoraj w necie
> że jakiś gość w maju 2022 szukał dokładnie tego samego. Jacyś ludzie mu
> coś tam podpowiadali, ale nie wynikało, czy już mu zadziałało, czy nie.
> Wynikało za to, że jeszcze nie znalazł tej 1-ki bo podał gdzieś tam
> nieparzysty adres tej funkcji, którą chce przenieść do RAM a w pliki map
> był adres parzysty.

1-ka moze zaskoczyc :-)


tu masz pomysl z druga funkcją - ale uprzedzam, ze kompilator z
linkerem moga je inaczej rozmieszczac
https://stackoverflow.com/questions/72089507/apm32-c
-copy-execute-function-in-ram

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.

J.

do góry

W dniu 2023-02-16 o 19:27, Marek pisze:
> On Thu, 16 Feb 2023 13:54:54 +0100, heby <h...@p...onet.pl> wrote:
>> Było to omawiane w tym wątku. Ogólnie, jesli ma to związek z
>> programowaniem flasha, to boje się zapytać, czy jakoś się
>> zabezpieczacie prze utratą zasilania w trakcie.
>
> 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.
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.

do góry

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

> Sugeruję jednak zapoznanie się ze skryptami linkera - zakładam, że
> używacie GNU toolchaina.

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.

> W sieci jest mnóstwo przykładów jak odczytać
> adres początku danej sekcji, jej końca, jej długość i jak wyeksportować
> te dane do linkowanego programu.
>
> Hint: Można sobie zdefiniować sekcję i umieścić w niej tylko jedną funkcję.

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 podstawy:
> https://developer.arm.com/documentation/ka002971/lat
est
> https://stackoverflow.com/questions/37004954/functio
n-address-in-arm-assembly-have-one-byte-offset
>
> Przy czym należy dodać, że Corteksy M (M-profile) wspierają tylko zestaw
> instrukcji Thumb/Thumb-2, a ten nieszczęsny bit został tam zapewne
> dlatego, że ,,duże ARM-y" (A-profile i R-profile) oprócz zestawu Thumb
> wspierają też zestaw instrukcji ARM.
>

To nasze (a właściwie mojego brata) pierwsze podejście do więcej niż
8-bitowych procesorów (ja nigdy nic na mikrokontrolery nie pisałem).
Właściwie to drugie podejście bo w grudniu już jedno urządzenie na
EFM32HG309F64G-C-QFN24 wypuściliśmy.
Na razie zostało nam kilkanaście (tymczasowo) zablokowanych urządzeń bo
nie umiemy jeszcze komunikować się z nimi po interfejsie Debug.
Skorzystaliśmy z ich defaultowego Bootloadera udającego RS232 na USB
przez który ładowaliśmy nasz bootloader (niszcząc ich) i pod nim
ładowaliśmy pierwszy program jako upgrade.
P.G.

do góry

W dniu 2023-02-17 o 20:23, heby pisze:
> On 17/02/2023 20:20, Piotr Gałka wrote:
>> Jak się chce modyfikować flash to kawałek funkcji ma być wykonywany z
>> RAMu.
>
> Możesz wskazać dokładnie ten pdf?
>

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:

https://www.silabs.com/documents/public/data-sheets/
efm32pg22-datasheet.pdf

lub (bardziej prawdopodobne) ten:

https://www.silabs.com/documents/public/reference-ma
nuals/efm32pg22-rm.pdf

Nie chce mi się szukać gdzie to jest bo ja tego drugiego nawet nie
przeglądałem. Brat mnie zawołał, podświetlił akapit na ekranie i chciał
usłyszeć jak ja to rozumiem.
P.G.

do góry

W dniu 2023-02-17 o 20:42, J.F pisze:
> tu masz pomysl z druga funkcją - ale uprzedzam, ze kompilator z
> linkerem moga je inaczej rozmieszczac
> https://stackoverflow.com/questions/72089507/apm32-c
-copy-execute-function-in-ram

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.

do góry

heby <h...@p...onet.pl> napisał(a):
> Więc co oznacza?

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

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

do góry

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:

__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

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

do góry

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.

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

> 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?

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.

do góry

On Fri, 17 Feb 2023 16:21:13 +0100, Grzegorz Niemirowski wrote:
> heby <h...@p...onet.pl> napisał(a):
>> Czyli sporej częsci urządzeń wyświetlajacych ten komunikat. Ja bym zaczął
>> od Windowsa. Co prawda to nie flash, ale w sumie co za różnica.
>
> Bo tak właściwie to ten komunikat wcale nie musi oznaczać, że coś wybuchnie
> jak wyłączysz nagle zasilanie. Windows nie psuje się od tego.

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.

do góry

On 17.02.2023 14:51, heby wrote:
> On 17/02/2023 10:17, JDX wrote:
>> [*] Co nie przeszkodziło ludziom wyrzeźbić na tym RP2040 (serca
>> Raspberry Pi Pico) - dwurdzeniowego MCU bez instrukcji wspierających
>> synchronizację. :-)
>
> Czekaj, czekaj... Tam nie było jakiś spinlocków sprzętowych? Mam, ale
> jeszcze nie programowałem, więc niewiele wiem praktycznie, ale jakiś
> ochłap tam dali.
>
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.

do góry