Marek wrote:

> On Mon, 12 Feb 2018 18:44:27 +0100, Bool <n...@n...com> wrote:
>> Możesz skrótowo napisać jak robiłeś to w przypadku z modemem GSM?
>
> Mcu przez stos tcpip modemu GSM pobiera sobie binarny plik obrazu
> firmware'u z serwera www. Stos większości modemów gsm umożliwia
> prostą komunikacje przez polecenia AT. Modem zestawia połączenie a
> mcu komendami AT wymienia sobie dane , można kawałeczkami pobrać
> sobie dowolnie duży plik. Kod pobierający nowy soft nie jest częścią
> bootloadera (bo byłby za duży) ale częścią softu użytkowego. W
> związku z tym, że soft użytkowy nie może się sam nadpisać (no, byłoby
> to klopotliwe, szczególnie gdyby np. połączenie zostało przerwane) to
> tymczasowo zapisuje pobrany obraz firmware'u w wolnym za sobą
> obszarze flash mcu (z pewnym marginesem) . Po wygraniu, robi reset po
> którym startuje bootloader, który sprawdza czy pod odpowiednim
> adresem jest obraz, jeśli jest kopiuje go pod docelowy adres
> nadpisując poprzedni firmware (i usuwa znacznik w tymczasowym obrazie
> by po kolejnym uruchomieniu nie kopiować ponownie). Tak w skrócie.
> Pominąłem takie szczegóły jak, to że pobierany firmware jest
> zaszyfrowany (klucz ma tylko bootloader i on deszyfruje dopiero przy
> docelowym nadpisywaniu), w trakcie pierwszego kopiowania do flash pod
> adres tymczasowy jest sprawdzane crc obrazu, by nie dopuścić do
> uruchomienia nieprawidlowego kodu itp.
> Aktualizacja ok 90kB obrazu pobieranego 256 bajtowymi paczkami po
> 9600bps uarcie mcu-modem trwa ok 4 min. Sama aktualizacja jest
> inicjowana smsem, komunikacja zwrotna w przypadku problemów z
> pobraniem pliku itp też jest smsem.
> Jeśli chodzi o szczegóły komunikacji to już to jest zależne od
> implementacji obsługi stosu w danym modemie, ja to ćwiczyłem na
> modułach G510.
>
Ale rozumiem, że musisz mieć ponad 2x więcej flasha niż rozmiar wgrywanego
kodu?

jp

--


www.flowservice.pl
www.flowsystem.pl