Wybór prostego protokołu dla bootloadera po UART: xmodem czy coś innego?

Alarm. Żołnierze lecą do magazynu uzbrojenia a system kontroli
dostępu:
"Proszę czekać, trwa aktualizacja"

Dla mnie przesyłanie pliku upgrade to przesyłanie go po kawałku aby nie przerywać normalnej pracy
urządzenia. A jak rozumiem Ty myślisz o przesłaniu całości jakąś jedną funkcją.

W dniu 2018-02-12 o 18:11, Piotr Gałka pisze:
Dla mnie przesyłanie pliku upgrade to przesyłanie go po kawałku aby
nie przerywać normalnej pracy urządzenia. A jak rozumiem Ty myślisz o
przesłaniu całości jakąś jedną funkcją.

U mnie upgrade wygląda tak że ładuję cały plik do flasha i weryfikuję
go. Jeśli weryfikacja przebiegnie OK to ustawiam flagę we flashu i robię
reset. Bootloader sprawdza zawsze flagę przy starcie i jeśli jest
ustawiona to rozpoczyna proces aktualizacji. Wtedy mam pewność że
załaduję zawsze poprawny firmware.

On Mon, 12 Feb 2018 18:44:27 +0100, Bool <no@no.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

Pytanie chyba raczej dotyczy tego czy bootloader moze być na tyle
pojemny
aby ogarnąć ten FAT i inne prymitywy niezbędne do gadania z SD card.

Ale rozumiem, że musisz mieć ponad 2x więcej flasha niż rozmiar
wgrywanego
kodu?

Sam kiedyś napisałem bootloader z xmodemem (*) i na dłuższą metę okazał
się dosyć upierdliwy, a na pewno jest problem z powiedzeniem
użytkownikowi końcowemu 'odpal minicoma, wciśnij cośtam, odpal lsz...'.

Ja się podepnę z pytanianiem:

Nie jestem jeszcze superbiegły w STM32 i bootloaderach.

Czy jest możliwe aby w np. STM32F103 jakoś tak przygotować/zbudować
bootloader aby mozna było zaciągać obraz flasha(fragmentu) z karty SD z
pliku obraz.bin (z FATu).
Oczywiście obsługę FAT mam ogarniętą.
Plik obraz.bin to skompilowany wsad który normalnie wpalam STLinkiem.
Pytanie chyba raczej dotyczy tego czy bootloader moze być na tyle pojemny
aby ogarnąć ten FAT i inne prymitywy niezbędne do gadania z SD card.

jp



chyba IAP bootloader od ST ma taką opcję

On Wed, 14 Feb 2018 09:21:33 +0100, jacek pozniak
jacek.pozniak@flowservice.pl> wrote:
Ale rozumiem, że musisz mieć ponad 2x więcej flasha niż rozmiar
wgrywanego
kodu?

Oczywiście. A dokładnie ciut więcej, bo;
1+2+3

1- bootloader
2- aplikacja.+ margines na rozwój aplikacji
3- tymczasowy bufor o rozmiarze z pkt 2

Dobierajac mcu do takuego projektu trzeba uwzględnić by dostępny
rozmiar flash uwzględniał powyższe punkty a szczególnie margines na
ewentualny rozwój aplikacji .

No nie będę mógł sobie na to pozwolić bo w urzadzeniu bedę miał zajeta około

A propos - co sie teraz mowi ?
porty szeregowe zniknely z peceta, a wraz z nimi hyperterminal w
Windows.

No nie będę mógł sobie na to pozwolić bo w urzadzeniu bedę miał
zajeta około
3/4 flasha (ze 128kB) a wiekszego procka na razie nie mogę dać bo
jest PCB

Zastanawiam się nad wyborem protokołu dla bootloadera po UART. Ma to być
prosty protokół, obsługiwany przez terminale pod Windows i Linux.
Wstępnie wybrałem xmodem. Czy warto zainteresować się jeszcze jakimś
innym protokołem?

W stm32 nie ma w tej samej obudowie kilka wariantów z pamięcią do
wyboru 128/256/512?
W tym co mam jest lqfp48 z max 128k.