Mogelijke gevaren van een bootloader bij een PIC

Op 13 januari 2010 17:19:48 schreef Skirmitt:
Hij denkt dat dit aan een te lage spanning lag waardoor de PIC zichzelf op één of andere manier defect geschreven heeft.

Dat mag hij eens uitleggen.

is best mogelijk.
stel dat je iets aan het wegschrijven bent nar eeprom. de voedingsspanning dipt effe waardoor er een addresdecoder verkeerd komt te staan... en huppekee je bent iets kwijt wat niet weg mocht.

Op die fiets... Maar is dat dan niet meer een kwestie van een slechte voeding/bad design?
Kan BOD het dan nog redden?

@FE: dat kan bijna niet, als je voorzorgsmaatregelen neemt; ten eerste doet de EEPROM logica het nog een stukje onder de brown-out grens, dus als de voeding voldoende buffercapaciteit heeft om de spanning nog een paar milliseconden hoog genoeg te houden, zal dat bijna altijd wel goed gaan. Als het mis gaat wordt (min of meer) gegarandeerd dat de data op adres 0 corrupt raakt; gebruik dat adres dan ook niet. Redundante data, checksums, etc. kunnen handig zijn als het echt veilig moet.

Desalniettemin; de code staat in Flash, en niet in het EEPROM. Je kunt niet per ongeluk in het Flash schrijven met een verkeerd adres, want in application mode is de Flash niet eens schrijfbaar.

Conclusie: waarschijnlijk heeft je collega een brakke, onvoldoende beveiligde bootloader gebruikt of zo. Ik heb wel eens bootloaders gezien die binnen een bepaalde tijd een bepaald karakter op de UART willen zien, en daarna alles wat ze ontvangen naar de Flash gaan schrijven. Dat is natuurlijk vragen om problemen.

Bij mij huidige baas hebben we ruim een half miljoen controllers van diverse fabrikanten in het veld staan, waarvan het grootste deel een, twee, of zelfs meer keren per jaar een update krijgt, en daar treden geen noemenswaardige problemen op.

ik lees termen zoals : 'bijna altijd' , 'als de voeding' ,

in princiepe moet het flash systeem zichzlf beschermen en de schrijfopdracht aborteren bij een brownout.

heeft de PIc wel een apart eeprom ? het zou me niet verwonderen dat dat fysiek geshared wordt ( zelfde vpp generator en dergelijke ... )

DIe code mag dan wel in flash staan, als je een bootloader hebt betekent het dat je de code flash kan schrijven tijdens runtime. anders kan je nooit een bootloader maken he ...

voor een deftig systeem voeg je zelf een externe power monitor toe.
je zorgt voor voldoende buffer capaciteit op de voeding en je knoopt de brownout detector 'voor' de spanningsregelaar op je bord. als je een dip constateert : interrupt naar de processor. die kan dan actie ondernemen. en als je echt zeker wil spelen : externe eeprom gebruiken voor systeemparameters in op te slaan. je interne flash alleen gebruiken voor code en alleen de bootloader access geven naar de schrijfroutines.

Altijd de self-write protection voor het bootloader gedeelte aanzetten, dan zou er (theoretisch) niets kunnen gebeuren. Ook altijd een 'skeleton' firmware in dat gedeelte opslaan, dat de MCU kan gebruiken, als de geladen firmware corrupt is geraakt.
Bij opstart testen of firmware goed is met checksum of crc...

Op 13 januari 2010 17:19:48 schreef Skirmitt:
Hij denkt dat dit aan een te lage spanning lag waardoor de PIC zichzelf op één of andere manier defect geschreven heeft. Is dit iets wat jullie al ervaren hebben ?

Hoe zit zijn bootloader in elkaar? Een 'velige' bootloader zit in in stuk flash dat (in de config fuses) write-protected is en altijd eerst opstart. Als dat corrupt raakt heb je iets raars gedaan, een power spike of dip is dan een eerste gok.

@FE: de PICs en AVRs die ik ken hebben echt een aparte EEPROM, ook omdat je die anders kunt lezen en schrijven dan Flash (elk byte apart), en veel vaker dan Flash. Een ongelukje met een schrijfactie in EEPROM die je Flash vernielt lijkt me zeer onwaarschijnlijk.

Een Flash schrijfactie starten kan eigenlijk niet per ongeluk, als het mis gaat, heb je dus zelf al iets fout gedaan. Als het echt zo gevaarlijk was, zou niet de hele wereld bootloaders gebruiken voor field-upgradability.

Op 13 januari 2010 21:12:32 schreef SparkyGSX:
Als het echt zo gevaarlijk was, zou niet de hele wereld bootloaders gebruiken voor field-upgradability.

Niet de hele wereld doet dat. Verhalen over corruptie van de bootloader komen vaker voor, al heb ik het idee dat dit vaak komt door verkeerd ontworpen bootloaders.

Als je toch een service monteur het veld in stuurt dan is een field-programmer of zelfs een laptop met een reguliere progerammer een prima oplossing. Als er al een PC aan het apparaat zit is voor een upgrade door de user is een bootloader natuurlijk wel makkelijker.

Op 13 januari 2010 21:37:12 schreef Wouter van Ooijen:
[...]

Niet de hele wereld doet dat. Verhalen over corruptie van de bootloader komen vaker voor, al heb ik het idee dat dit vaak komt door verkeerd ontworpen bootloaders.

Als je toch een service monteur het veld in stuurt dan is een field-programmer of zelfs een laptop met een reguliere progerammer een prima oplossing. Als er al een PC aan het apparaat zit is voor een upgrade door de user is een bootloader natuurlijk wel makkelijker.

Als je enkele klanten hebt met een redelijk custom design in je nabije omgeving dan is het best te doen om een field engineer met een laptop er op uit te sturen

maar als je wereldwijd hetzelfde aantal apparaten uit hebt staan dan is het ineens wel erg kostbaar om die veldwachter er op uit te sturen..

Klopt. wij hebben verschillend echips waar ene ROM bootloader in zit ( echte metalmask ROM) . Die bootloaders gaan meestal een blok peripherie initialiseren ( SDRAM controller bijvoorbeeld ) , kijken of er iets bruikbaar in de flash zit. indien ja , dna wordt dat overgekopieerd naar de sdram en gestart. Die code bevat dan meestal een self-decompressor. Meestal zit er in de flash een filesysteem met daarin gecomprimeerde files. er is 1 'executable' die een paar kilobyte is en de echte loader /decompressor bevat. dat is de zogenaamde secondary loader. aLs die ontbreekt gaat de primary loader ( die uit de ROM ) een seriele poort openen of een UDP poort met ene vast IP adress als we een netwerk hebben. en luisteren naar wat daar binnenkomt. er draait een simpel protocol waarmee we een intel hex file kunnen doorvlammen naar ram en dan tegen de bootloader zeggen : voer dat ding uit. Zo kan de ROM klein blijven. we hebben enkel transport nodig. niks anders. eenmaal een initilese loader geladen is neemt die dan over om de rest van het memory te flashen met binnenkomende data.
Er zijn ene aantal protecties. de ROM bootloader kijkt naar bepaalde markers in de flash. zijn die er niet : wacht op instructies. Als het normaal programma draait zijn er een paar watchdogs. als het programma om een of andere reden corrupt geraakt zullen er bepaalde zaken niet gebeuren. op dat moment schoppen we het ganse systeem terug naar bootloader uit rom.

Het schrijven naar flash terwijl je voedingsspanning soms raar doet is tricky hoor! Op sommige AVR kan je als ik het me goed herinner tot zo'n 2V gewoon draaien, maar om te kunnen flashen moet er minimaal 3V (of zo) zijn. Om normaal op 2V te kunnen draaien, kan je de BOD op 2.2V zetten, maar dat is dus al te ver voor het flash-gebeuren.

Ok, tijdens het flashen zou het fout kunnen gaan, maar we hadden het over corrupt raken tijdens normaal bedrijf, en niet tijdens het flashen, toch?

In ons geval is er geen monteur van ons in de buurt als de controllers geflasht moeten worden; sterker nog, de printen waar de controllers op zitten, is niet eens bereikbaar. De enige manier om het ding van nieuwe software te voorzien, is dus over de communicatiebus. Tot dusver gaat dat prima, het ding is, vanwege de bootloader die controleert of het programma wel geldig is, zelfs bestand tegen een afgebroken download. Dat hoeft allemaal niet echt groot of ingewikkeld te zijn; eenvoud is de sleutel van een goede bootloader, want de kans dat daar iets grandioos fout gaat ook een stuk kleiner. Een andere techniek is natuurlijk een dubbel boot image, waardoor je ook na een verkeerde download nog een goede kopie van de applicatie code hebt, alleen heb je daarvoor dus twee keer zoveel program memory nodig. In sommige gevallen kan dat een goede optie zijn.

Bedankt voor de zeer nuttige antwoorden. Hebben jullie er baat bij als ik de broncode post ? Deze is opgemaakt in een CCS compiler.

Op 14 januari 2010 13:08:37 schreef Skirmitt:
Hebben jullie er baat bij als ik de broncode post ?

Kan jij zelf niet nagaan hoe de bootloader precies werkt?

Natuurlijk, mijn kennis gaat echter niet ver genoeg om nu al te zien waar het potentieel verkeerd kan lopen in de bootloader.