Diskuze - danyk.cz

Vlákno z kategorie: Hlavní diskuze
Celkem 17 odpovědí.


24.10.2020 (16:27:03) K # IP X
deny hoch obalka :
Zdravím místní osazenstvo diskuze,
Po delší odmlce, kdy nebylo moc času (práce, děti, žena atd.) jsem také "prý" chytil tu populární chřipku a jelikož mám 14 dní nucené dovolené doma, opět jsem oprášil svoji vstupně-výstupní kartu na Ethernet s PoE. PoE funguje - trochu problémů bylo, ale odstranil jsem :)
Každopádně bych se chtěl zeptat na BootLoader pro STM32 (konkrétně STM32G030). Potřeboval bych si "napsat" svůj vlastní, abych mohl kartu přehrávat na dálku (bude to někde na střeše a tam se mi moc lézt s NTB nechce) ... Komunikační čip pro ETH je W6100. Vím, že tu Wiznet moc rádi nemáte, ale nyní prosím o toleranci. Čip funguje dobře :) Takže po spuštění bootloaderu by bylo nutno inicializovat SPI sběrnici, komunikaci s tímto čipem a až pak nějak začít přepisovat stránky v FLASH paměti dle dat z PC. Programování FLASH paměti v běžící aplikaci používám celkem běžně kvůli uložení proměnných.

Otázka zní, programoval tu někdo něco takového ? Budu rád za každou pomoc, děkuji.
25.10.2020 (15:46:50)  # IP X
VroutekB:
Na takovýhle hrátky bys měl mít spíš procesor s dualbank FLASH, protože během zápisu do / výmazu FLASHe z ní nelze číst. Tzn kód, který musí ject trvale buď musí běžet ze SRAM (a to včetně tabulky vektorů a ISR), nebo musíš počítat s tím, že bude CPU v době zápisu prostě zaseknuté a nebude dělat nic - což zrovna si nemyslím, že je vhodný chování aplikace s ETH portem, nýbrž fungovat by to asi fungovalo i tak.
Zadruhý, FLASHky bys měl mít dostatek na dva firmwary současně, jinak při neúspěšným natažení novýho FW ti zařízení přestane fungovat, dokud nedostane správný FW (za předpokladu, že v bootloaderu budeš mít kompletní obsluhu ETHernetu a všech protokolů, což s některýma složitějšíma protokolama je docela dost dat a postrádá trochu smyslu mít tam tu obsluhu dvakrát: Jednou v hlavním FW a podruhý v bootloaderu.
Bootloader jediný co by měl řešit po spuštění je, který ze dvou firmwarů je platný a ten spustit, případně přehodit na ten novější. Veškerá aplikační obsluha vč. ETH protokolů bude potom součástí samotného FW, ne bootloaderu. I proto se používá dualbank FLASH, aby aplikace nerušeně jela se vším všudy, zatímco lifruje nový FW do druhého banku FLASHe.
25.10.2020 (15:52:03)  # IP X
VroutekB:
Jo, ještě jedna podstatná věc, proč by bootloader neměl řešit obsluhu ETH, ale měl to dělat až aplikační FW: Protože bootloader se nedá později aktualizovat. Proto je vhodné, aby byl co nejjednodušší s nejmenším potenciálem nutnosti opravy případných chyb. Když necháš chybu v bootloaderu, který obsluhuje celý ETH, tak jsi prakticky bez šance ho opravit nadálku.
25.10.2020 (19:03:29)  # IP X
deny hoch obalka :
Děkuji za odpověď, Vroutku.

Trochu jsem se v tom ztratil, tak kdyžtak omluv moje nesmyslné dotazy :)
Moje představa byla, že bych třeba na poslední stránku v FLASH paměti nahrál bootloader, který by obsahoval vše potřebné k chodu - ETH inicializaci, protokol atd.. Následně by začal přehrávat vše od první stránky podle dat z PC. Máš pravdu, že pokud se nenatáhne správně FW, aplikace zkolabuje a zařízení nebude fungovat vůbec - to mě nedošlo.

Do dalšího projektu plánuji použít STM32F446 kvůli rychlosti a bude zde použita i 128Mb FLASH paměť zapojena přes SPI - tato by šla použít jako "zásobárna" nového FW, tak že by hlavní aplikace nahrála nový FW do externí FLASH a nahodila nějaký bitík, který by se četl při startu CPU. Pokud by byl tento bitík nahozený, bootloader při překopírovat FW z externí FLASH do hlavní FLASH v procesoru a spustil aplikaci. Tento "překopírovací" bootloader by mohl sedět na poslední stránce v procesorový FLASH. Výhoda je, že by byl vždy k dispozici FW. Úskalí, které vidím, je, že takovýto bootloader nebude univerzální pro více aplikací.

Co si o tom myslíš ?

Děkuji za pomoc :)
25.10.2020 (19:30:12)  # IP X
deny hoch obalka :
A nešel by bootloader nahrát do SRAM ? Z hlavní aplikace v FLASH bych skočil do SRAM, kde bych spustil bootloader, který by následně přehrál FLASH a po dokončení by skočil zpět do FLASH.
Kdysi jsem to takto používal v AVR. NEvím, jestli by to tady taky tam nešlo.
Díky :)
25.10.2020 (22:44:01)  # IP X
VroutekB:
To co se ti snažím vysvětlit je, že bootloader by neměl řešit žádný protokolový vrstvy - zejména ne v aplikaci s ETH, kde je víc než pravděpodobné, že bude časem potřeba aktualizovat třeba i samotný protokol nebo ETH stack. Bootloader jen vybírá FW, kterej spustí. Pak tam potřebuješ akorát místo na da firmwary, ideálně dualbank device.
26.10.2020 (15:15:50)  # IP X
RayeR (web) :
Presne tak, i ja ti rikam do bootloaderu zadny takovy hi-level veci necpat! Bootloader ma byt co nejjednodussi a spolehlivy aby se nemusel uz menit.
My sme to meli udelane zhruba takto: SMT32 mel pripojenou SPI flahs jako ulozsiste s jednoduchym souborovym systemem, aplikace ve flash CPU byl takovy maly OS, ktery umel obsluhovat cany, wifiny, eternety a po techto kanalech prenaset data a tedy i novy FW. Ten se tma poslal jako komprimovany balicek opatreny CRCem, a ulozil se na souborovy system se specialnim atributem. Po restartu se bootloader podival jesi nema ulozeny soubor s novym FW s tim atributem a pokud ano, tak ho za behu rozbaloval a cpal do druhe banky flash. Zaroven bootloader kontorloval integritu FW ve flash a pokud byla spatna (treba po nedokoncenem predchozim flashi), tak se spustila zalozni verze FW, ktera se bezne neprehravala. Pokud by se nak poskodila i ta, tak to zustalo viset v bootloaderu a slo to prehrat z konzole po seriovy lince (poslanim toho sameho komprimovaneho balicku).

Samozrejme je mozny si i kod bootloaderu nahrat do SRAM a pak nemas flash blookovanou - tusim ze takle funguje i ten bootloader co je tam od vyrobce co se aktivuje boot0,1 pinama, a nejpsis i to co komunikuje s ST-Linkem, v adresari FlashLoader je spousta nakych binarek pro ruzne rady MCU, ktere se asi nahravaji do SRAM, ale to sem nikdy nezkoumal...
26.10.2020 (15:24:16)  # IP X
RayeR (web) :
>deny hoch
BTW na AVR si mohl tezko neco pouste ze SRAM, nebot procak neumoznuje vykonavat kod ze SRAM, je to harvard a navic do te pidiSRAM by se nic neveslo. Asi si mel na mysli bootlader sekci na konci interni flash...
26.10.2020 (17:54:07)  # IP X
deny hoch obalka :
Děkuji Vám oběma :)

Zamotali jste mi hlavu, ale jsem rád, že jsem se o tom dozvěděl více :) Máte pravdu v tom, že mít záložní FW někde ve FLASH paměti je nesmírná výhoda. Dualbank FLASH podporují jen G4, H7 a F7, což je pro mě takový kanón na vrabce (rozměry pouzder, výkon, cena). Taková G0, F4 (kterou jsem teď namaloval do jednoho z dalších projektů) bohužel nic takového nemá a nevím, jestli by FLASH dokázala pojmout dva FW + bootloader - u tý G0 se mi to tam nevejde.
Ano, dá se to řešit externí FLASH, ale ta v každém projektu s ETH nebude.

A ta SRAM zůstane v nezměněném stavu i při vypnutém napájení ? Z principu RAM dostávám odpověď že "NE", ale celkem mě tam mate písmenko "S" (static ?).

Díky za reakce.
26.10.2020 (18:11:10)  # IP X
RayeR (web) :
SRAM je pamet, ktera nepotrebuje periodicky refresh, to nijak nesouvisi s tim, jesi udrzi data po vypnuti. Nicmene snad vsechny STMka maj nakej Vbat pin pro zalozni napajeni, kterym jde SRAM zalohovat...
27.10.2020 (07:03:31)  # IP X
deny hoch obalka :
Děkuji za odpovědi.

Ještě jedna věc, na kterou bych se rád zeptal - lze v paměti FLASH nějak skákat na jiné adresy ? Myslím to tak, že po splnění určitých podmínek skočím na (třeba) poslední stránku v FLASH, vykonám jednoduchý bootloader a následně skočím zpátky na začátek hlavní aplikace. V AVR jsem to takto praktikoval :)

Děkuji.
27.10.2020 (07:03:35)  # IP X
deny hoch obalka :
Děkuji za odpovědi.

Ještě jedna věc, na kterou bych se rád zeptal - lze v paměti FLASH nějak skákat na jiné adresy ? Myslím to tak, že po splnění určitých podmínek skočím na (třeba) poslední stránku v FLASH, vykonám jednoduchý bootloader a následně skočím zpátky na začátek hlavní aplikace. V AVR jsem to takto praktikoval :)

Děkuji.
27.10.2020 (16:29:29)  # IP X
RayeR (web) :
Na ARMu mas vsechno v jednom 32b adresnim prostoru, tak si muzes skakat kde chces, pokud ten blok neni zrovna nak deaktivovanej.
27.10.2020 (19:08:57)  # IP X
RayeR (web) :
Jinak je ale potreba davat bacha, kam mas nasmerovany vektory preruseni, asi neni dobry aby byly aktivni zrovna v ty casti flash, kerou prepisujes... AVR na to melo ten fuse bit, kterej to prehodil, jak je to u STM presne nevim...
27.10.2020 (20:52:05)  # IP X
deny hoch obalka :
Díky.
Vektory přerušení = funkce, které se volají při přerušení ? (void SysTick_IRQHandler(void)). Vím, že se ptám až na moc velké banality, ale chci to správně pochopit :)
RayeR, dal by jsi mi na sebe nějaký email nebo jiný kontakt, že bychom si napsali někde mimo ? Tedy pokud by nevadilo :)

Děkuji.
28.10.2020 (03:07:15)  # IP X
RayeR (web) :
mail mam na webu, ale necejtim se k tomu zas tak kompetentni, je to uz nejmin rok, co sem naposled neco pro STM32 psal, a tak daleko, abych si tam psal bootloadery sem se zatim nedostal. AVRka mam teda zazity vic. Takze bych stejne odkazal na nake vroutkovy oblibene ref. manualy, ci postahovani uz nakyho fcniho projektu bootloaderu nekde z netu a vubec, tuhle fajnovost bych si nechal na potom, az to budes mit zvladnuty, treba ten eth. nebude uplne prdel, zalezi co za knihovny pouzijes, co a do jaky hloubky budes muset delat sam...
28.10.2020 (17:51:27)  # IP X
deny hoch obalka :
Děkuji ti.
Referenční manuály používám, bohužel moje angličtina není perfektní (věk, zaměření atd.), takže často tápu, co a proč tak je :)

Na tvůj web jsem koukal, velice zajímavé čtení. Hlavně v kategorii elektroniky.
31.10.2020 (14:54:06)  # IP X
VroutekB:
Na ARMu se tabulka vektorů ISR přemisťuje prostým zápisem do registru SCB->VTOR
Přezdívka:
Heslo:
Text: