Utformning och implementering av
distribuerad mjukvarunedladdning
i ett inbyggt system
JONATHAN WADELIUS
Utformning och implementering av
distribuerad mjukvarunedladdning
i ett inbyggt system
Jonathan Wadelius
Examensarbete MMK 2010:44 MDA 328 KTH Industriell Teknik och Management
Det här examensarbetet skrevs på och i samarbete med Plockmatic International AB, Stockholm.
Bilden på framsidan föreställer ett system för sortering, vikning och kuvertering, © Plockmatic International AB.
Nyckelord: Distribuerad mjukvarunedladdning, inbyggda system, Controller Area Network, CAN, mikrokontroller.
Examensarbete MMK2010:44 MDA 328 Utformning och implementering av distribuerad
mjukvarunedladdning i ett inbyggt system Jonathan Wadelius Godkänt: 21 Maj 2010 Examinator: Martin Törngren Handledare: Magnus Persson Uppdragsgivare: Plockmatic International AB Kontaktperson: Patrik Dahlqvist
Sammanfattning
Plockmatic International AB har sedan 1974 utvecklat och tillverkat maskiner för pappershantering. De gör idag maskiner för bland annat häftestillverkning och ku-vertering. I maskinerna finns CAN-bussar med upp till tio noder med mikrokon-troller. Vid mjukvaruuppdatering måste varje nod uppdateras för sig. Detta är tidskrävande. Det finns därför behov av centraliserad uppgradering.
En litteratustudie genomfördes och olika sätt att lösa centraliserad installation av mikrokontroller undersöktes. Vikt lades på hur installationen kan göras säker och verifieras. Modeller över hur centraliserad uppgradering kan utföras utformades. Ett system för centraliserad uppgradering av Plockmatics maskiner utvecklades. Genom att koppla in en dator till en nod på CAN-bussen med hjälp av protokollet RS232 kan noder på nätverket uppgraderas. En programvara för PC med opera-tivsystemet Windows har utvecklats för att hantera ny mjukvara och sända den till maskinen. Programmet kan utifrån kommunikation med noderna avgöra om uppgradering krävs.
När uppgradering sker så installeras alla noder utom en parallellt. En bestämd mängd data sänds från persondatorn till en nod. Istället för att vänta på ett svar om att datan installerats korrekt så skickas data till en annan nod direkt. Den första nodens svar läses av datorn när det är den nodens tur att ta emot mer. Orsaken till parallelliteten är att det tar lång tid för persondatorn att upptäcka inkomna meddelanden. Med den här metoden försvinner tidsfördröjningen. Den enda noden som inte uppgraderas parallellt med de andra är noden som översätter meddelanden mellan RS232 och CAN. Den uppgraderas istället sist. Verifieringen som utarbetats togs emellertid inte med på grund av tidsbrist.
Uppgraderingen av noder har testats med de olika versioner av mikrokontroller som Plockmatic använder. En CAN-buss med fem noder har uppgraderats. Trots att verifiering inte implementerats installeras noder korrekt. Den parallella instal-lationen minskar tidsåtgången. Fortsatt arbete krävs dock för att slutgiltigt kunna implementera systemet i Plockmatics maskiner.
Master of Science Thesis MMK2010:44 MDA 328 Design and Implementation of Distributed Software
Download in an Embedded System Jonathan Wadelius Approved: May 21 2010 Examiner: Martin Törngren Supervisor: Magnus Persson Commissioner: Plockmatic International AB Contact Person: Patrik Dahlqvist
Abstract
Plockmatic International AB has since 1974 developed and produced machines for document finishing. Today they make mailing feeders and booklet makers among other things. The machines are equipped with CAN buses with up to ten nodes with microcontrollers. In the event of a software update each node has to be updated individually. This is time-consuming. There is hence a need for centralised updating of software.
A literature study was conducted and different methods of centralised microcon-troller installation were investigated. Emphasis was placed on how the installation could be made safe and be verified. Models of how centralised upgrading can be done were developed. A system for centralised upgrading of Plockmatic machines was developed. By connecting a computer to a node on the CAN bus via the pro-tocol RS232 the nodes on the bus can be upgraded. A Windows PC application has been developed to handle new software and send it to the machine. Based on communication with the nodes the application can determine if an upgrade is nescessary.
When the upgrade is performed all nodes but one are installed in parallel. An amount of data is sent from the personal computer to a node. Instead of waiting for a response the computer directly sends data to another node. The response from the first node is read the next time the application intends to send to that node. The reason for the parallel approach is that it takes a while for the PC to handle new messages. With this method the delay at each received message is removed. The only node that is not upgraded at the same time is the translating node. The verification that was developed was not implemented because of lack of time.
Upgrading of nodes has been tested with the different versions of microcontrollers that Plockmatic use. A CAN bus with five nodes has been upgraded. Nodes are installed correctly even though verifying has not been implemented. The parallel upgrade decreases the time used. More work is however needed to implement the system in Plockmatic’s machines.
Förord
Det här examensarbetet är genomfört åt Plockmatic International AB och Kung-liga Tekniska Högskolan KTH under vintern och våren 2009/10. Examensarbetet har utförts hos företaget och deras utrustning har använts.
Jag vill rikta ett stort tack till Patrik Dahlqvist och Peter Olofsson på Plockmatic för stöd under arbetets gång och för hjälp med tekniska frågor. Jag vill också tacka min handledare på KTH, Magnus Persson för hjälp med frågor och rapport. Till sist vill jag tacka de som läst och kommenterat rapporten.
Innehåll
1 Introduktion 1 1.1 Syfte . . . 1 1.2 Mål . . . 1 1.3 Avgränsning . . . 2 1.4 Frågeställning . . . 2 1.5 Metod . . . 3 1.5.1 Litteraturstudie . . . 3 1.5.2 Utformning av modeller . . . 3 1.5.3 Genomförande . . . 3 2 Bakgrund 5 2.1 Plockmatic International AB . . . 5 2.1.1 Maskinen DMI 4000 . . . 52.2 Controller Area Network . . . 6
2.3 RS-232 . . . 7 2.4 Mikrokontroller . . . 7 2.5 Förutsättningar . . . 7 3 Litteraturstudie 9 3.1 Metoder för mjukvaruuppgradering . . . 9 3.1.1 Traditionell uppgradering . . . 9
3.1.2 Uppgradering via nätverk . . . 10
3.1.3 Hårdvaruberoende . . . 10
3.1.4 Filformat . . . 12
3.2 Säkerhet . . . 13
3.2.1 Typer av fel . . . 13
3.2.2 Metodik för säker uppdatering . . . 14
3.2.3 Inbyggt skydd i CAN-protokollet . . . 15
5 Genomförande och Resultat 37 5.1 Verifiering . . . 37 5.2 Utvecklingsverktyg . . . 37 5.2.1 Versionshantering . . . 37 5.2.2 LPC2292 . . . 38 5.2.3 M16C . . . 38 5.2.4 PC . . . 38 5.2.5 CAN . . . 39 5.3 Skillnader i hårdvara . . . 39 5.3.1 M16C . . . 39 5.3.2 LPC2292 . . . 39 5.4 Kommunikation . . . 40 5.4.1 RS232 . . . 40 5.4.2 Meddelandeprotokoll . . . 41 5.5 Initiering . . . 42 5.5.1 Inkoppling . . . 43
5.5.2 Mjukvaruversion och räknare . . . 43
5.5.3 Datafiler . . . 44 5.5.4 Mikrokontroller . . . 45 5.6 Uppgradering . . . 46 5.6.1 Parallellitet . . . 46 5.6.2 Felhantering . . . 47 5.6.3 Mikrokontroller . . . 48 5.6.4 Flödesscheman . . . 49 5.7 Demonstrator . . . 53
Kapitel 1
Introduktion
Det här examensarbetet utförs på Plockmatic International AB och på Kungliga Tekniska Högskolan, KTH. Plockmatic utvecklar, producerar och mark-nadsför utrustningar för pappershantering − kuvertering, falsning, plockning, häft-ning, bindning och papperssortering. Maskinerna är utvecklade för användning on-line tillsammans med högvolymkopiatorer och skrivare eller som fristående system. Plockmatic utvecklar allt från små skrivbordsmaskiner till stora produktionsmask-iner för industrin. Denna vidd på maskinstorlekar gör att styrsystemen består av allt från ett styrkort till distribuerade styrsystem bestående av tio stycken krets-kort.Controller Area Network (CAN) protokollet används i styrsystemen. För att ladda mjukvara till kretskorten ansluts idag en programmeringskabel fysiskt till varje kort och enheterna uppdateras individuellt.
1.1 Syfte
Att mjukvaran på varje kretskort måste uppgraderas separat kan bidra till problem om den som utför arbetet inte är utbildad på maskinen. Det är även tidskrävande. Därför finns det behov av ett system med central uppgradering, det vill säga uppgradering av flera kort samtidigt över nätverket från en punkt.
1.2 Mål
Målen med examensarbetet är att:
• Utreda hur mjukvaruladdning till kretskort kan ske över CAN-nätverket.
2 KAPITEL 1. INTRODUKTION
• Utveckla rutiner på de olika kretskorten så att de kan ta emot mjukvara över nätverket.
• Utveckla ett PC-gränssnitt för att uppdatera kretskort.
1.3 Avgränsning
Examensarbetet har följande begränsningar:
• Endast de hårdvaror som finns i Plockmatics maskiner ska utredas, det vill
säga Renesas M16C/6N och NXP LPC2292 med ARM7.
• Examensarbetet ska inriktas mot kuverteringsmaskinen DMI 4000.
• Uppgraderingen ska ske via den interna CAN-bussen (ICAN).
• Mjukvaran till mikrokontrollerna ska skrivas i programmeringsspråket C. Mjukvaran till persondatorn ska skrivas i C#.
1.4 Frågeställning
När teori för mjukvaruladdningen ska utredas ska följande frågor besvaras: 1. Vilka metoder finns för nedladdning av mjukvara via CAN?
2. Hur ska systemet konstrueras för att säkra att mjukvaran kommer fram intakt?
När mjukvaruladdningen ska utvecklas ska följande frågor besvaras:
3. Vad finns det för begränsningar i systemet Plockmatic använder?
4. Vilket protokoll ska användas för uppdateringen? 5. Hur ska persondatorn fysiskt kopplas in i styrsystemet?
6. Fungerar en nod i systemet som ladd-master vid nedladdningen?
7. Hur hanteras Flashminnet med bootblock och sektorer?
Vid utvecklandet av ett gränssnitt för persondatorn ska följande frågor besvaras: 8. Hur hämtar persondatorn mjukvaruversionerna på kretskorten för att
säker-ställa att rätt version laddas ned?
1.5. METOD 3
1.5 Metod
Följande metod har använts under examensarbetet.
1.5.1 Litteraturstudie
Examensarbetet inleddes med att studera litteratur om mjukvaruuppdatering och hur den kan göras säker. Vikt lades på olika metoder att verifiera installerad mjuk-vara. De protokoll som används i Plockmatics maskiner studerades.
1.5.2 Utformning av modeller
Med litteraturstudien som grund utformades först en teoretisk modell som beskriv-er hur ett system för mjukvaruuppgradbeskriv-ering kan lösas på ett bra och säkbeskriv-ert sätt. Med hjälp av möten och dialog med ingenjörer på företaget anpassades modellen till en implementeringsmodell som är praktiskt genomförbar.
1.5.3 Genomförande
Kapitel 2
Bakgrund
Det här kapitlet beskriver företaget Plockmatic och dess produkter. Även nätverket som används i produkterna redogörs för.
2.1 Plockmatic International AB
Plockmatic utvecklar, producerar och marknadsför utrustning för Document Fin-ishing. Företaget grundades 1974 och har ett antal produkter för varierande voly-mer och uppgifter. De inkluderar papperssortering, plockning, häftning, falsning, bindning och kuvertering. Maskinerna kan användas i applikationer från on-line med högvolymskrivare och kopiatorer till fristående med manuell matning. Plock-matic säljer maskinerna under eget namn men även som delar av system från till exempel Xerox och Ricoh. [1]
2.1.1 Maskinen DMI 4000
Den maskin som examensarbetet inriktar sig mot är i första hand kuverteraren DMI 4000. Maskinen har 10 stycken motorkort och ett styrkort, se figur 2.1. Bak-grunden till examensarbetet är att Plockmatic vill kunna uppdatera alla kort på ett nätverk från en punkt, till exempel styrkortet som i figuren. Maskinerna är modulära och sitter ofta ihop med andra moduler från Plockmatic eller skrivare. De innehåller två nätverk, även kallade bussar, baserade på protokollet CAN. Mer om CAN i 2.2 nedan. Då flera moduler sitter ihop sammanlänkas de via CAN-nätverket XCAN, medan det interna CAN-nätverket heter ICAN. DMI 4000 kommer också i en variant med ett separat användargränssnitt med en pekskärm, som då sitter inkopplat på XCAN.
6 KAPITEL 2. BAKGRUND ICAN-bus Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort Motor-kort XCAN-bus UI-kort Annan maskin Styr-kort
Figur 2.1: Schematisk beskrivning av nätverket i en DMI 4000.
Ett meddelande på det interna nätverket ICAN innehåller maximalt 8 bytes data. Varje motor i maskinerna har en unik identifierare. Varje identifierare har 11 bitar. En nod i nätverket använder den identifierare som tillhör första motorn på kortet som sin identifierare. Ett stort antal meddelanden finns reserverade för olika typer av operationer [2]. ICAN kör med 1 Mbit/s.
Nätverket XCAN har liksom ICAN 8 bytes data. Varje nod på nätverket har en unik identifierare på 29 bitar. Ett stort antal meddelanden finns reserverade. Det sker omfattande kommunikation mellan olika maskiner i systemet för att reglera flödet av ark och häften mellan modulerna. XCAN använder liksom ICAN en överföringshastighet på 1 Mbit/s. [3]
2.2 Controller Area Network
2.3. RS-232 7
2.3 RS-232
I datorteknikens korta historia är Recommended Standard 232 (RS-232) riktigt gammal. Arbetet på standarden började 1960. 1963 hade den redan uppdater-ats en gång och kallades RS-232-A. Numera heter standarden EIA-232-F, men eftersom RS-232 är den vanligt förekommande benämningen används det nam-net i rapporten. Standarden skapades från början för att möjliggöra standardis-erad kommunikation med modem från olika tillverkare. Genom att ett stort antal företag stödde standarden började den användas för annat än det ursprungliga användningsområdet och levde vidare. När persondatorerna slog igenom var det standard att använda RS-232. Detta då protokollet används i COM-portar [5]. Numera håller RS-232 på att fasas ut och ersättas av USB. Det är inte längre standard med COM-portar på bärbara datorer, även om de fortfarande är vanliga på stationära datorer. RS-232 är enkel seriell kommunikation och passar väl för att skicka och ta emot information med mikrokontroller. Detta eftersom många mikro-kontroller har stöd förUniversal Asynchronous Receiver/Transmitter (UART) som är kompatibelt med RS-232. Det är endast spänningsnivåerna som skiljer RS-232 och UART åt. Protokollet har visst stöd för feldetektering med hjälp av en paritets-bit [6]. Mer om paritet i 3.2.4. RS-232 baseras på att skicka en ström av tecken. Detta har att göra med protokollets ursprung för modemkommunikation. Antalet bitar i varje tecken varierar men 7 till 9 bitar är vanligt förekommande. Förutom tecknet har varje Byte en start- och en stoppbit. Stoppbitens längd kan varieras mellan en och två bitar. Om paritet är aktiverat tar även den en bit i anspråk.
2.4 Mikrokontroller
Mikrokontroller är en typ av små enchips-datorer utrustade med fysiska portar så att de kan läsa av och styra extern utrustning. De kan läsa av till exempel en elektronisk termometer eller knappsats och styra en motor, solenoid eller en display. Mikrokontrollers finns i mängder av utrustning runt omkring oss. Programmen brukar lagras i minnen som antingen går att radera och skriva om eller som bara kan skrivas en gång. Flash hör till den typ av minne som går att radera och skriva om. Programmen brukar skrivas med språket C eller i vissa fall språkfamiljen
Assembler. Det förekommer även andra språk, till exempel C++. [7]
2.5 Förutsättningar
8 KAPITEL 2. BAKGRUND
Kapitel 3
Litteraturstudie
Litteraturstudien i det här examensarbetet har delats in i två delar, metoder för
mjukvaruuppgradering och säkerheten för uppgraderingen. Detta eftersom de är två
viktiga aspekter på uppdatering av mjukvara i ett distribuerat system. I introduk-tionen i kapitel 1 finns två frågeställningar som rör uppgradering och verifiering. De återfinns i respektive del där de besvaras.
3.1 Metoder för mjukvaruuppgradering
Vid mjukvaruuppgradering finns flera tillvägagångssätt. En av frågeställningarna som ska besvaras i det här examensarbetet är:
1. Vilka metoder finns för nedladdning av mjukvara via CAN?
3.1.1 Traditionell uppgradering
Vid traditionell uppgradering kan antingen mikrokontrollern flyttas till ett pro-grammeringskort, programmeras över seriell kommunikation eller via en JTAG. JTAG står för Joint Target Action Group, och följer en IEEE-standard för programmering och debugging av mikrokontrollers [8]. Endast vissa mikro-kontroller stöder JTAG.
Vid den seriella metoden programmeras mikrokontrollern på plats utan att behöva flyttas från kretskortet. Detta kallas vanligtvisIn-System Programming (ISP) och finns i olika typer hos många leverantörer av mikrokontrollers. Mikrokontrollern startas i ett särskillt läge genom att vissa pinnar sätts höga eller låga och data skrivs till Flashminnet. Proceduren är långsam och kräver att programmerings-kortet sätts i direktkontakt med mikrokontrollern [9, 10]. Vissa varianter, som till
10 KAPITEL 3. LITTERATURSTUDIE
exempel LPC2292 från NXP, kan programmeras direkt via seriell kommunikation [9]. Andra varianter måste ha specialhårdvara på kretskortet för att få samma funktionalitet, alternativt använda en programmeringshårdvara som kopplas in vid uppdateringstillfället [11]. Det är vanligt att RS-232 används för att programmera mikrokontroller.
3.1.2 Uppgradering via nätverk
Många mikrokontrollers har idag stöd i hårdvaran som möjliggör uppgradering eller programmering via nätverk. Att uppgradera via nätverk har flera fördelar enligt Riessland [12]:
• Snabbare programmeringshastighet.
• Flera enheter kan uppgraderas i direkt följd.
• Den som utför uppgraderingen slipper koppla in sladdar på varje enhet som ska uppgraderas.
När mikrokontrollers ska uppdateras via nätverk används vanligtvis en teknik som kallasIn-Application Progamming (IAP).
In-Application Programming
IAP finns i många typer av mikrokontrollers, däribland LPC2292 och M16C/6N. Vid IAP aktiveras kod i användarens program och mikrokontrollern uppgraderas därigenom. En illustration av IAP visas i figur 3.1. I flashminnet finns ett »Huvud-program« och ett »Uppgraderings»Huvud-program« lagrat. När en uppdatering ska ske initieras den över nätverket. Det första som sker i mikrokontrollern efter initierin-gen är att uppdateringsprogrammet kopieras till RAM-minnet, illustrerat av pil 1 i figuren. Detta eftersom mikrokontrollers vanligtvis inte kan läsa från flash-minnet under omprogrammering. Uppdateringsprogrammet tar sedan emot det nya huvudprogrammet och sparar det i RAM, se pil 2 i figur 3.1. När detta är klart skrivs huvudprogrammet till flashminnet, illustrerat av pil 3 i figuren. [9, 10, 13]
3.1.3 Hårdvaruberoende
3.1. METODER FÖR MJUKVARUUPPGRADERING 11 Flash RAM Uppgraderings-program Uppgraderings-program Huvudprogram
μK
1 3 CAN-bus Nytt huvudprogram 2Figur 3.1: Illustration av In-Application Programming i en mikrokontroller på en CAN-bus.
och modell. Vissa modeller har inbyggt stöd för uppgradering via CAN, medan andra måste få specialmjukvara för att uppnå samma funktionalitet. [9, 10] Ett exempel implementerar mjukvaruuppgradering via en så kallad bootloader, ett program som startar vid mikrontrollerns start och som finns installerat från fabrik, se [14]. Detta illustreras i figur 3.2. Själva mjukvaran varierar eftersom hårdvaruregister och andra delar av mikrokontrollern ser olika ut.
PC
PC-CAN Card
HyperTerminal or Other Terminal Firmware
RS-232
Target Board
CAN Module Serial Communication Firmware
PC-CAN Card to Target Board Communication
Target Board to PC-CAN Card Communication Firmware
CAN Module
CAN Bus
Figur 3.2: Uppgradering via bootloader. [14]
12 KAPITEL 3. LITTERATURSTUDIE
istället två sektorer som reserveras för uppgraderingsprogrammet, utan att vara boot-sektorer. Uppdateringsprogrammet kopieras till RAM, Flash raderas och det nya programmet mottas över CAN. När programmet skrivits till Flash verifieras det med hjälp av kontrollsummor. De tre exemplen [14, 15, 16] är alla från andra tillverkare av mikrokontroller än de som Plockmatic använder. Detta för att visa att den underliggande hårdvaran till trots så implementeras mjukvaruuppgrader-ing på liknande sätt.
3.1.4 Filformat
När program kompilerats och länkats behöver de sparas i ett format som kan laddas till en mikrokontroller. De två formaten som används av Plockmatic beskrivs här.
Intel hex-format
Intel hex är ett format som skapats för att spara och ladda binär information. Informationen är sparad som ASCII-text i en fil som har ändelse.hex. Filformatet är populärt för att spara kompilerade och länkade program innan de laddas ned till en mikrokontroller. Varje rad i en .hex-fil innehåller information. I figur 3.3 visas ett exemple på en rad och vad de olika fälten betyder. Kontrollsumman är i tvåkomplementsform och beräknas på alla Bytes utom kolonet. För mer om kontrollsummor, se 3.2.4. [17] : 10 0170 00 707172737475767778797A7B7C7D7E7F 07 Start Antal Bytes data som följer Startadress Typ av information, här data Data, 16 (0x10 ) Bytes K on trollsumma
Figur 3.3: Exempel på en rad ur en .hex-fil. [17]
Motorola S-format
3.2. SÄKERHET 13
.mot. Den binära informationen finns representerad som ASCII-text, och är på det hela taget lik Intel hex. Samma fält som finns i Intel hex finns representer-ade i Motorolas S-format, men i annan ordning, se figur 3.4. Kontrollsumman är i enkomplementsform, och beräknas på den binära representationen av alla Bytes med undantag för de två första. [17]
S 1 13 0170 707172737475767778797A7B7C7D7E7F 03 Start Typ av information, här data 19 (0x13 ) Bytes följ er Startadress Data Kon trollsumma
Figur 3.4: Exempel på en rad ur en .mot-fil. [17]
3.2 Säkerhet
När säkerhet behandlas i examensarbetet är det med betoning på datasäkerhet. Säkerhet i meningen risk för personskada behandlas inte eftersom det finns byggd säkerhet i uppgraderingsproceduren. När en uppgradering ska ske finns in-struktioner om att bryta spänningsmatningen till motorerna, vilket stänger av alla rörliga delar.
Det finns olika metoder för att verifiera att kod som skickats har installerats kor-rekt. Det är även viktigt att veta att överföringen inte skadar data som skickas. I examensarbetet ska följande fråga besvaras:
2. Hur ska systemet konstrueras för att säkra att mjukvaran kommer fram intakt?
3.2.1 Typer av fel
Vid feldetektering finns det olika typer av fel som metodern i varierande grad upptäcker. Felen brukar delas in i två kategorier.
14 KAPITEL 3. LITTERATURSTUDIE
1 0 1 0 1 0 1 0 ↓
1 1 1 0 1 0 1 0
Figur 3.5: Bitfel, en bit har bytt värde (kursivt). [18]
Den andra kategorin heter på engelska burst error, och kallas i det här examens-arbetet för skurfel. Med ett skurfel menas att två eller flera bitar har bytt värde. Bitarna behöver inte ligga intill varandra, det kan finnas opåverkade bitar mellan dem, se figur 3.6.
←− Längd −→
1 0 1 0 0 0 1 0
↓ ↓ ↓
1 1 1 1 1 0 1 0
Figur 3.6: Skurfel, flera bitar har bytt värde (kursivt). Felets längd är fyra bitar. [18]
3.2.2 Metodik för säker uppdatering
Cao et al. [19] har visat att det är möjligt att genomföra IAP i ett system som kräver höggradig säkerhet såsom en pacemaker. Trots att en pacemaker kan verka vara helt skild från ett system för kuvertering finns vissa likheter. Den pacemaker som Cao et al. använde innehåller en mikrokontroller,Texas Instruments MSP430, som är jämförbar med de mikrokontroller Plockmatic använder [20]. Metoden för IAP som Cao et al. använde är därför relevant att studera.
Som datalänk har pacemakers elektromagnetisk kommunikation. På så vis kan läkare läsa ut data om patienten från pacemakern. Eftersom det är en tvåvägs-kommunikation och mikrokontrollern stödjer IAP är programmering möjligt. För att säkerställa programmeringen användes av Cao et al. en särskild procedur med kommunikation innan mikrokontrollern gick in i uppdateringsläget. När upp-gradering skedde följde den steg som illustreras i figur 3.7.
3.2. SÄKERHET 15 Flash RAM Uppgraderings-program Informations-lagring Uppgraderings-program
μK
Nytt huvudprogram 2 Huvudprogram Version 1 Huvudprogram Version 2 Tom plats 1 Tom plats n 1 3 Elektromagnetisk datalänk …..Hand-dator
Figur 3.7: Illustration av In-Application Programming i en pacemaker så som det imple-menterades av Cao et al. [19].
För att minska programstorleken i mikrokontrollern flyttade Cao et al. så myck-et funktionalitmyck-et som möjligt till handdatorn. Även adresserna i minnmyck-et dit data skrevs hanterades av handdatorn. Dessa skickades med varje datapaket. Mikro-kontrollern behövde därför inte ha kod som sparar adresser och uppgifter om var data skrivs. Den behövde endast ta emot och kontrollera paketens kontroll-summa. Handdatorn inväntade en godkäntsignal från pacemakern efter varje paket för att säkerställa att data inte går förlorad. Om uppgraderingen av någon an-ledning avbröts sparades läget så att uppgraderingen kunde fortsättas senare. Mikrokontrollern verifierade datans kontrollsumma innan den skrevs från RAM-till Flashminnet.
Mjukvaran i handdatorn var utvecklad för att vara användarvänlig, och hade därför bara två knappar. Den ena knappen användes för att öppna en fil för installation på pacemakern, och den andra för att starta installationen. Filen som valts kontroller-ades först för att säkerställa dess äkthet och versionsnummer. Sedan kontrollerkontroller-ades versionen i pacemakern för att säkerställa att en uppgradering behövdes. Samman-taget ger de funktioner som beskrivits här ett system med hög inbyggd säkerhet.
3.2.3 Inbyggt skydd i CAN-protokollet
CAN, är ett nätverksprotokoll med hög inbyggd säkerhet [4]. Sannolikheten för ett oupptäckt fel blir med CAN endast F · 4, 7 · 10−11 där F är felfrekvensen. Följande feldetekteringsmekanismer är implementerade:
16 KAPITEL 3. LITTERATURSTUDIE
• Cyclic Redundancy Check, CRC, är ett kraftfullt verktyg för att upptäcka fel. Mer om det i 3.2.4.
• När en sändande nod skickat fem bitar med samma logiska nivå stoppar den automatiskt in en bit med motsatt nivå. Den biten tas automatiskt bort av mottagarna. Detta kallas »Bit Stuffing«.
• Meddelanden måste följa vissa ramformat. Om en eller fler bitar inte har rätt nivå enligt specifikationen så orsakar det ett fel.
Förutom ovanstående nämnda mekanismer har nätverket felöverensstämmelse. Om en nod uppfattat ett meddelande som felaktigt kommer alla noder att förkasta meddelandet och begära omsändning genom att alla noder som uppfattar ett fel flaggar för det. Alla noder kommer i och med att en nod flaggat för fel betrakta meddelandet som korrupt. På så vis accepteras ett meddelande av alla eller inga noder. Den sammantagna felhanteringen resulterar i följande prestanda:
• Alla nätverksvida fel upptäcks.
• Alla lokala fel vid sändning upptäcks.
• Upp till fem slumpmässigt placerade bitfel i ett meddelande upptäcks.
• En skur av felaktiga bitar med längd kortare än 15 upptäcks.
• Ett fel med ojämnt antal bitar upptäcks.
CRC är ett kraftfullt verktyg för att upptäcka fel, se 3.2.4. En kort förklaring är att CRC beräknar fram en nyckel utifrån en datamängd, som kan användas för att verifiera att datamängden är intakt. I CAN-protokollet beräknas en nyckel utifrån följande delar av meddelandet; startbiten, identifieraren som avgör vilka noder meddelandet ska levereras till, datalängden och datan. Nyckeln skickas med meddelandet. Varje nod beräknar om nyckeln och jämför med den medskickade. Om nycklarna inte stämmer överens meddelas detta och allt skickas om.
3.2.4 Verifiering av Flash
3.2. SÄKERHET 17
Maxino [21] jämförde ett flertal kontrollsummor och CRC, både analytiskt och genom simulering. De jämförda var i ordning av prestanda; XOR, tvåkomple-mentsaddition, enkompletvåkomple-mentsaddition, Adler- och Fletcher-kontrollsumma samt CRC. De som Maxino bedömde som bäst i respektive beräkningskostnadsklass var enkomplementsaddition om det inte finns möjlighet till så mycket beräkningar, Fletcher-kontrollsumma där det finns möjlighet till viss beräkning, och CRC om det finns specialhårdvara eller möjlighet till mer beräkning. Detta sammanfattas i tabell 3.1.
Feldetektering Beräkningskostnad Metod
Hög CRC
Medel Fletcher
Låg Enkomplementsaddition
Tabell 3.1: De metoder som enligt [21] är bäst i olika beräkningsklasser.
Enligt tidigare forskning skulle Adler vara lika bra som Fletcher om inte bättre, men det visades i [21] att så inte var fallet. Maxino visade även att Adler och Fletcher inte är lika bra som en välfungerande CRC, vilket vissa tidigare resultat antytt. Enligt Jain [22] har Fletcher fördelen att den är enkel att implementera och beräkna i mjukvara, medan CRC är bättre lämpad för implementation i hårdvara. Nedan följer närmare beskrivningar av de olika metoderna Maxino kom fram till var bäst. Även paritetstest beskrivs eftersom det är en enkel metod som många känner till.
Paritetstest
En enkel men inte speciellt säker metod för feldetektering är paritetstest. Paritet är metoden för feldetektering som ingår i den gamla standarden RS-232. Feldetek-teringen går ut på att räkna ettorna i ett meddelande. Om jämn paritet är vald kommer en extra bit, kallad paritetsbiten, att se till att antalet ettor blir jämnt. Om istället udda paritet valts kommer paritetsbiten få ett värde som säkerställer ett ojämnt antal ettor [23]. Detta illustreras i tabell 3.2. Paritetstest upptäcker alla enbitsfel, men många fel med fler bitar förblir oupptäckta.
Data Jämn Udda
0 1 1 0 0 0 1 1 0 1
0 1 0 1 0 0 0 1 1 0
18 KAPITEL 3. LITTERATURSTUDIE
Enkomplementsaddition
Den av de enkla varianterna av kontrollsumma som enligt [21] var bäst är enkom-plementsaddition. Metoden är enkel eftersom den endast går ut på addering. Ett exempel på hur enkomplementsaddition fungerar kan ses i tabell 3.3 [18]. I tabellen illustreras hur fyra 8-bitars bytes adderas. Resten från kolumn 8 adderas med del-summan, och sedan tas komplementet, det vill säga bitvis invertering, på summan. Resultatet fungerar som kontrollsumma.
1 ←Rest från kolumn 8, adderas till delsumman 1 . . . 1 . . . ... 1 . . . ... ... 1 . . . ... ... ... 1 . . . ... ... ... ... 1 . . . ... ... ... ... 1 0 ←Rest från kolumn 1 0 0 0 1 0 1 0 1 1 1 1 0 1 0 0 1 1 0 0 0 0 0 1 1 0 0 0 0 1 0 1 1 1 0 0 0 1 1 1 0 Delsumma 1 Rest från kolumn 8 1 0 0 0 1 1 1 1 Summa 0 1 1 1 0 0 0 0 Kontrollsumma
Tabell 3.3: Enkomplementsaddition för att beräkna en kontrollsumma [18].
3.2. SÄKERHET 19
Fletcher-kontrollsumma
Den ovannämnda problematiken med ordningen på datan löses med Fletcher-kontrollsumman. Metoden implementerar vägning så att ordningen i vilken data förekommer har betydelse. Vid bytes från D0 till Dn itereras en viktad kontroll-summa fram, se algoritm 3.1. Fletcher är den näst bästa av feldetekteringsme-toderna enligt [21].
Algoritm 3.1 Viktad kontrollsumma med hjälp av Fletcher. Bytes från D0 till
Dn. B och A sätts samman till en kontrollsumma med storlek 2 Bytes. [21] Initiering: A = B = 0 Iteration medan i ≤ n: A = A + Di B = B + A Slutförande: B A CRC
CRC är ett kraftfullt verktyg för att upptäcka fel. Till skillnad från andra fel-detekteringsmekanismer är CRC inte baserat på addition, utan binär division och är därmed dataoberoende. Därmed är prestandan är oberoende av datainnehållet [21]. CRC går ut på att i första steget dela datamängden och ett antal binära nollor med ett förutbestämt värde. Det är inte resultatet av divisionen som är intressant, utan resten, se tabell 3.4a. När datamängden kontrolleras för fel sätts resten från föregående beräkning ihop med datamängden istället för nollorna, se tabell 3.4b. Om resten från den andra beräkningen blir noll är datamängden intakt. [18] Det binära värde som datamängden divideras med kallas för CRC-polynom. Vid användning av CRC är det viktigt att ett välfungerade polynom väljs. Det polynom som används i exemplen i tabell 3.4 är x3+ x2 + 1. Detta polynom genererar det binära tal som används för divisionen genom att varje x motsvarar en etta på en position. Avsaknad av i det här fallet x1 orsakar en nolla på den positionen. Ett
polynom ska inte vara delbart med x, och ska vara delbart med x + 1.[18]
3.3. SLUTSATS 21
kunna ersättas med bättre varianter [24]. Ett dåligt val av polynom kan göra CRC ett sämre val än Fletcher, som kräver mindre beräkningskraft[21].
3.2.5 Feldetektering stödd av hårdvara
Många mikrokontroller har inbyggt stöd för feldetektering. Om en modell till ex-empel innehåller en CAN-modul ingår de mekanismer som CAN-specifikationen anger. Andra mikrokontroller har inbyggt stöd för att åtgärda fel i Flash under körning. Vissa mikrokontrollermodeller har även en särskild CRC-modul som med hjälp av hårdvara kan utföra effektiv CRC-beräkning. [9, 10]
3.3 Slutsats
Vid uppgradering via nätverk är utformningen beroende av hårdvaran. Vissa mikro-kontroller har inbyggt stöd för uppgradering via CAN, till andra måste program skrivas. Även de mikrokontroller som har inbyggt stöd kan behöva program som gör IAP, beroende på det inbyggda stödets utformning och egenskaper.
Den metod som Cao et al. [19] utvecklat för att säkerställa att det alltid finns en fungerande version av mjukvaran har studerats. Metoden innehöll även intressanta aspekter rörande användarvänlighet.
Det skydd som finns inbyggt i CAN gör att nätverksprotokollet är mycket säkert. Sannolikheten för att ett fel inte upptäcks är mycket liten. Därför kan det antas att den data som kommer fram med CAN är felfri. Däremot finns det fortfarande risk att andra fel uppstår.
Flera varianter av feldetekteringsmekanismer studerades. Den mest effektiva av dem är CRC, som också är den metod som kräver mest beräkningskraft. Det är viktigt att ett bra polynom väljs, annars kan lika gärna Fletcher användas. Vissa mikrokontroller har inbyggt CRC-stöd, nackdelen med den lösningen är att CRC-polynomet är fast och inte kan skräddarsys efter ändamålet. Enkomplements-addition bör inte implementeras då feldetekteringen är för dålig.
Det har varit svårt att hitta akademiska artiklar om mjukvaruuppgradering av mikrokontroller. Uppgradering är befintlig teknik, det finns därför inte intresse hos forskare att skriva om det. Maxino [21] har legat till grund till graderingen av kontrollsummor och CRC. Det examensarbetet är noga utfört och visar med flera metoder hur feldetekteringsmekanismerna förhåller sig till varandra.
Kapitel 4
Utformning
Vid utformning av mjukvarunedladdning finns flera områden som är viktiga att ta hänsyn till, vilket beskrivs i detta kapitel. Inledningsvis utvecklades en första modell. Den bortser från flera begränsningar och är utarbetad som en teoretisk modell. Därefter anpassades den första modellen till vad som var praktiskt genom-förbart vid möten med ingenjörer på företaget. Den andra modellen användes sedan vid implementeringen av systemet. Kapitlet börjar med en genomgång av hårdvaruberoende faktorer.
4.1 Hårdvaruberoende faktorer
Vid programmering av mikrokontroller är många faktorer hårdvaruberoende, vilket gör att utformningen måste anpassas efter dem.
4.1.1 Uppgradering
Vid uppgradering av mikrokontroller via nätverk finns olika metoder som används i modeller från tillverkarna Renesas och NXP vilka Plockmatic använder [9, 10]. Metoderna skiljer sig åt och olikheterna beror till viss del på hårdvaruspecifika faktorer. De metoder som finns tillgängliga i Plockmatics mikrokontrollers kommer att beskrivas nedan.
NXP LPC2292
LPC2292 stöder ISP och IAP. Vid ISP startas ett laddningsprogram från start-sektorn och ny data kan skrivas över seriell kommunikation. Startstart-sektorn är en
24 KAPITEL 4. UTFORMNING
del av Flashminnet som startar när mikrokontrollern slås på. ISP kräver att hård-varan startas om, och att vissa pinnar sätts höga eller låga. Startsektorn läser av pinnarna och exekverar sedan antingen ISP-koden eller användarens program om sådant finns installerat. [9]
Mikrokontrollern har stöd för IAP då ett användarskrivet program exekveras i RAM och kopierar data från det minnet till Flash. Innan IAP kan genomföras måste sektorerna i Flash-minnet förberedas för skrivning så de inte längre skyddas. Samma förfarande gäller om sektorer ska raderas. Initiering av programöverföring från RAM till Flash sker genom att minnesadresserna till datan skrivs i särskilda register. [9]
Renesas M16C/6N
M16C/6N har flera möjligheter för mottagande av program. Förutom vanlig ISP
via seriell kommunikation finns även ISP via parallell kommunikation, då större befogenheter finns. Vid den parallella laddningen kan även startsektorn, »Boot Area«, programmeras. I startsektorn finns programmen som tar emot uppda-teringar via seriell kommunikation samt över CAN, kallat »CAN I/O Mode«. De programmen förinstalleras på Renesas-fabriken. Om startsektorn inte har installer-ats om finns de kvar. [10]
Mikrokontrollern har även två sorters IAP, kallade EW0 och EW1. Dessa kan radera och skriva till Flash oberoende av vilket medium det nya programmet lev-ereras med. I tabell 4.1 jämförs de två metoderna. Det speciella med EW1 är att programmet inte behöver kopieras till RAM för exekvering. Detta fungerar om mikrokontrollern har en dedicerad sektor som bara innehåller uppdaterings-program. Uppdateringsprogrammet kan i så fall installera om resten av Flash. [10]
4.1.2 Feldetektering
Det förekommer att mikrokontroller har inbyggt stöd för feldetektering. Detta underlättar och kan snabba upp exekveringstiden vid till exempel användandet av kontrollsummor. Här redogörs för det stöd för feldetektering som finns i hårdvaran.
LPC2292
4.1. HÅRDVARUBEROENDE FAKTORER 25
Egenskaper EW0 EW1
Arbetssätt • Standardläge • Minnesexpansionsläge • Startläge • Standardläge Minne där uppgraderings-programmet kan lagras • Användarsektorerna • Startsektorn • Användarsektorerna Minne där uppgraderings-programmet exekveras Uppgraderingsprogrammet måste flyttas till ett annat minne än Flash (t.ex. RAM) innan exekvering.
Uppdateringsprogrammet kan exekveras i
användarsektorerna. Minne som kan
skrivas om
Användarsektorerna. Användarsektorerna, utom de sektorer där uppdaterings-programmet finns lagrat.
Mjukvaru-begränsningar
• Inga begränsningar. • Program- och
sektorraderings-kommandon kan inte exekveras i en sektor där uppdateringsprogrammet finns sparat.
• Kommandot »Radera alla olåsta sektorer« kan inte exekveras om sektorn med
uppdaterings-programmet är olåst. Tabell 4.1: Metoder för programmering, EW0 och EW1. Deltabell från [10].
lagrad på en separat plats i Flash som användaren inte har tillgång till. Vid varje läsning kontrolleras Flash mot kontrollsumman. Om ett bitfel upptäcks korrigeras det innan datan lämnas till processorn. Detta är transparent för användaren. [9]
M16C/6N
Den andra mikrokontrollern, M16C/6N, har inbyggt hårdvarustöd för CRC som kan anropas av användaren. Polynomet som finns i hårdvaran är x16+ x12+ x5+
26 KAPITEL 4. UTFORMNING
att jämföra med tidigare värden får CCITT-16 ∼ 1 · 10−13 vid datamängder på 2048 bitar. Dessa värden är utlästa ur diagram från [21]. Diagrammet sträck-er sig till 65536 bitar varför det inte går att veta hur polynomet betsträck-er sig vid större datamängder. Trenden i diagrammet är att avståndet mellan CCITT-16 och Fletcher ökar. CCITT-16 ligger inom två gånger det teoretiska minimumet i spannet 1015-2048 bitar [24].
4.2 Teoretisk modell
Här redogörs för den första modellen över utformningen av systemet. Gemensamt för avsnitten under 4.2 är att när de ska implementeras ska mjukvaran skrivas så att samma kod kan användas oberoende av hårdvara. Drivrutinerna ska vara så anpassade att funktionerna har samma namn och tar samma argument. Detta un-derlättar vid portering till ny hårdvara. För flödesscheman som beskriver avsnitten se 4.2.6.
4.2.1 Kommunikation
I den här modellen används två kommunikationsprotokoll, RS232 och CAN. Det som är svagast säkerhetsmässigt är RS232. Med andra ord är det RS232 som är den svaga länken och där fel lättast uppstår. Eftersom protokollet används för mjukvaruuppdatering för kretskort i Plockmatics maskiner finns det på samtliga enheter kontakter att koppla in på. Även om traditionella serieportar blir mer och mer ovanliga så är det enkelt att koppla in sig via en USB till RS232-adapter. Det finns en modell av sådan adapter som Plockmatic rekommenderar, som används vid implementeringen. Det finns dessutom bra stöd i datorer för att använda RS232 med så kallade COM-portar. Ett alternativ vore att koppla in persondatorn direkt på CAN-bussen med hjälp av en adapter. Det finns dock inte alltid tillgängliga CAN-kontakter i maskinerna, och alla som ska uppdatera en maskin måste utrustas med en ny adapter. Lösningen med RS232 gör därför att befintliga adaptrar och sladdar som servicepersonalen redan har tillgång till fungerar.
4.2.2 Initiering
4.2. TEORETISK MODELL 27
då likt CAN-identifieraren högst prioritet [4]. Detta utnyttjas då datorn beordrar samtliga noder att rapportera in sitt ID och installerad version av mjukvaran. Noden med högst prioritet får övertaget när noderna försöker svara samtidigt. När den är klar får noden med näst högst prioritet skicka, och så vidare. I Plockmatics CAN-specifikation finns meddelanden reserverade för modell- och versionsnummer, vilka används i modellen. Datorn avgör utifrån den informationen vilka noder som behöver installeras om. För att få full bandbredd på bussen skickar datorn ut en order till noderna att gå in i tyst läge. De kommer då inte att skicka på CAN om de inte får direkta frågor tills de fått order om att tyst läge upphört.
4.2.3 Uppgradering
När uppgraderingen börjar installeras noderna i ID-ordning. Först installeras noden med högst prioritet, följt av näst högst prioritet och så vidare. Om en nod med en viss prioritet inte behöver uppgraderas utlämnas den. För att spara tid börjar nod 2 uppgraderas när nod 1 verifierar. Detta medför att flera processer körs parallellt. Om en nedladdning tar 2 minuter och en verifiering 1 minut då körs sekvensiellt, kommer uppgradering av 10 noder att ta 30 minuter. Om verifieringen sker paral-lellt och resultatet av den kommuniceras efter alla nedladdningar är klara tar hela processen lite mer än 20 minuter. Då de körs parallellt sparas nästan 10 minuter. Denna uträkning baseras på att en nod som verifierar inte behöver kommunicera i stor utsträckning. Om en verifiering kräver mycket kommunikation måste även den tiden adderas. Om flera noder ska ha samma mjukvara uppdateras de parallellt. En översikt av uppgradering av en nod i den första modellen av systemet finns i figur 4.1. 1 PC CAN-bus RAM Flash Uppdaterings-program Nytt huvudprogram Nod 3 4 RAM Flash Uppdaterings-program Nytt huvudprogram Styrkort 2 5 6
Figur 4.1: Schematisk illustration av mjukvarunedladdningens utformning.
nedladdnin-28 KAPITEL 4. UTFORMNING
gen och styrkortet. Kommunikationen sker över det seriella protokollet RS232. Styrkortet översätter detta till CAN och sköter kommunikationen på CAN-bussen, illustrerat av pil 2. Styrkortet är programmerat för att lägga uppdateringsprogram-met och de program som ska skickas vidare på mellanlagring i RAM-minnet. Även i mottagarchippet läggs det mottagna programmet i RAM. I figuren är endast ett mottagarkort inritat, men i verkligheten innehåller nätverket flera kort. Om programmet som ska skrivas är större än RAM-minnet, skrivs den del av pro-grammet som får plats i RAM till Flash, se pil 3. Sedan hämtas fortsättningen av programmet över CAN-bussen. Om även styrkortet behöver uppdateras sker samma procedur även där. Den del av programmet som får plats i RAM skrivs till Flash innan ytterligare data hämtas till RAM, se pil 5. Flashminnet verifieras (pil 4 och 6). Mer om verifiering i 4.2.5.
När uppgraderingen ska avslutas skickastyst läge slut till alla noder. Noderna kan då fortsätta som vanligt.
4.2.4 Säkerhet
Säkerheten är alltid ett problem vid mjukvaruuppgradering. Om överföringen av mjukvaran av någon anledning bryts finns risken att den inte kan återupptas vid ett senare tillfälle.
Flash RAM Uppgraderings-program Informations-lagring Uppgraderings-program
Nod
Nytt huvudprogram 2 Huvudprogram Version 1 Huvudprogram Version 2 Tom plats 1 Tom plats n 1 3 ….. CAN-bus 5 4Figur 4.2: Metod för att säkra uppgraderingen. Pilar utan fylld spets visar förflyttning av data. Pilar med fylld spets visar programpekare.
4.2. TEORETISK MODELL 29
av sektorerna används för att lagra en version av programvaran. När en ny ver-sion ska installeras skrivs den till andra sektorer, utan att påverka de tidigare versionerna. Efter att uppgraderingen initieras kopieras mjukvaran som ska utföra uppgraderingen till RAM (pil 1). Ett nytt huvudprogram hämtas över CAN och mellanlagras i RAM (pil 2). Programmet skrivs till en tom plats och använder så många sektorer som behövs (pil 3). Antalet sektorer som används för att lagra en version är inte fast utan anpassas till storleken på mjukvaran. Programmet veri-fieras (pil 4) och när det är säkerställt att det är intakt flyttas programpekaren från den tidigare versionen till den senaste (pil 5). Det sista steget är viktigt, det säkerställer att mikrokontrollern kan starta med fungerande mjukvara även om uppgraderingen avbröts till exempel genom att strömmen bröts. Ett program som inte är kontrollerat kommer inte att kunna starta eftersom att programpekaren pekar på en tidigare version innan verifiering.
För att säkerställa att fel mjukvara inte laddas i en maskin är styrkortets versions-nummer unikt för varje modell. På så vis kan mjukvaran i persondatorn avgöra om det är rätt maskin den är inkopplad till.
4.2.5 Verifiering
Summor som beskriver Flashminnet räknas ut och skickas till datorn för jämförelse med ett facit vilket räknats ut i datorn i förväg. Alla nyinstallerade noder vän-tar med att skicka in nycklarna till all uppgradering är klar. På så vis störs inte pågående uppgradering. Om nyckeln inte stämmer överens med facit ominstalleras noden. I alla M16C/6N sker verifieringen med det inbyggda hårdvarustödet. I LPC2292 verifieras minnet med mjukvaruimplementerad CRC. För att vara kon-sekvent använder LPC2292 samma CRC-polynom som finns i M16C/6Ns hårdvara.
4.2.6 Flödesscheman
I det här avsnittet redovisas flödesscheman som visualiserar4.2.2 Initiering, 4.2.3
Uppgradering och 4.2.5 Verifiering. Alla flödesscheman är ritade enligt
IBM-stand-ard [25].
30 KAPITEL 4. UTFORMNING Start i PC Noderna uppgraderas i ID-nummrens prioritetsordning Verifiering sker parallellt med nästa uppgradering Uppgradering Mjukvara installeras i noder Verifiering Den installerade mjukvaran verifieras Initiering Initiera uppgradering Uppgradering Mjukvara installeras i noder Order: Tyst Läge Slut Slut. Visa resultat
32 KAPITEL 4. UTFORMNING
4.3 Implementeringsmodell
Efter att den teoretiska modellen utarbetats anpassades den till vad som var prak-tiskt genomförbart genom möten med ingenjörer på företaget. Resultatet blev en implementeringsmodell som användes som bas vid implementeringen. Här redo-visas skillnader mellan implementeringsmodellen och den teoretiska modellen.
4.3.1 Kommunikation
Den svagaste länken när det gäller kommunikationen är RS232, inte bara ur säker-hetssynpunkt. På grund av att datorns operativsystem, Windows, inte har realtids-möjligheter eller avbrott orsakade av inkommande RS232 via USB kan kommu-nikationen bli långsam trots att processorns klockfrekvens är hög. Detta illustreras i figur 4.5. Från det att ett meddelande kommit in tar det tiden T tills kommu-nikationsprocessen får köra. Om det kommer många bekräftelsemeddelanden är det risk att kommunikationen blir långsam, om processen måste vänta varje gång. Detta orsakas av att Windows inte har avbrott för RS232 via en USB-adapter, vilket är det som används vid uppgraderingen. Vid fast COM-port finns stöd för avbrott, men sådana portar är nu ovanliga i bärbara datorer. Vid mobil uppgrader-ing ute hos en kund används bärbara datorer med den USB till RS-232-adapter som Plockmatic säljer.
Kommunikationsprocessen Andra processer Kommunikationsprocessen Tiden T Meddelande kommer in Tid
Figur 4.5: Meddelandeproblematiken. Med för många bekräftelser från styrkortet kan kommunikationen bli långsam. Det tar tiden T innan kommunikationsprocessen får köra och kan hantera det inkomna meddelandet.
4.3. IMPLEMENTERINGSMODELL 33
viktigt att utreda om prestandan blir bäst om mikrokontrollern som agerar brygga mellanlagrar data eller på direkten skickar meddelanden vidare ut på CAN.
4.3.2 Initiering
Eftersom det bara sker kommunikation på CAN-nätverket då maskinen kör är det onödigt med tyst läge. Noderna svarar bara om styrkortet skickar någon form av begäran. Det enda fall då noderna självmant skickar meddelanden är om någon lucka på maskinen öppnas, men ett sådant meddelande är kort och skulle inte störa en uppgradering.
4.3.3 Uppgradering
Enligt den teoretiska modellen ska styrkortet mellanlagra data som en buffert in-nan data skickas vidare. Det kan vara att föredra att styrkortet är helt transparent för kommunikationen, och bara skickar vidare meddelanden som kommer in utan att buffra. Det kan dock vara så att det behövs en buffert på grund av hur datorn skickar data. Om data kommer stötvis kan det vara fördelaktigt med en mellan-lagring som ser till att kommunikationen på CAN-bussen kommer mer jämt. Detta måste utredas under implementeringen. För att förenkla kommer noder med sam-ma program i ett inledningsskede att uppgraderas sekvensiellt. Boot-sektorerna kommer inte att modifieras, utan endast de sektorer som är tillgängliga för använ-dare kommer uppdateras.
4.3.4 Säkerhet
34 KAPITEL 4. UTFORMNING
4.3.5 Verifiering
Det är inte säkert att den lösning för verifiering som valts i den teoretiska modellen är mest effektiv. Det kan vara enklare och lika effektivt att verifiera i noden innan datan skrivs till Flash. När datan sedan skrivits kan den läsas och jämföras mot det som finns i RAM. Det måste utredas och testas vilken version som är mest effektiv.
4.3.6 Flödesscheman
4.3. IMPLEMENTERINGSMODELL 35 Initiering CAN translate mode Order: Noder rapportera in Noder rapporterar in ID, modell och mjukvaruversion Noderna svarar i ID-nummrens prioritetsordning Behövs uppgradering? Nej Ja Slut. Visa resultat
(a) Schema över initieringsflödet, utan
tyst läge. Start i PC Slut. Visa resultat Noderna uppgraderas i ID-nummrens prioritetsordning. Verifiering sker innan skrivning till Flash Uppgradering Mjukvara verifieras och installeras i noder Initiering Initiera uppgradering
(b) Huvudflödet blir förenklat då ingen parallellitet längre finns.
Uppgradering Styrkort vidarebefodrar på CAN A Noder mellanlagrar i RAM
RAM fullt? Nej
Program skrivs till Flash Ja Hela programmet i Flash? Ja Nej Verifiera meddelande för meddelande Läs Flash och Jämför med RAM (c) Uppgraderingsflödet får nya block då verifieringen sker integrerat med uppgraderin-gen.
Kapitel 5
Genomförande och Resultat
I det här kapitlet redovisas utvecklingsarbetet och det resulterande systemet för uppgradering av Plockmatics maskiner.
5.1 Verifiering
På grund av den knappa tiden för projektet kunde tyvärr inte verifieringen inklud-eras i implementeringen. Verifieringen är en viktig del för att säkerställa att en uppgradering gått rätt till och att den nya mjukvaran kommer fungera. Effekten av att verifiering nu saknas är att oupptäckta fel kan uppstå som ger plötsliga krascher eller oförklarligt beteende.
5.2 Utvecklingsverktyg
Utvecklingsarbetet påverkas av de utvecklingsverktyg som finns tillgängliga. Här beskrivs de utvecklingsverktyg som använts i examensarbetet.
5.2.1 Versionshantering
För att säkerställa att koden inte går förlorad vid en eventuell datorkrasch och för att kunna jämföra olika versioner användes det versionshanteringssystem som används på Plockmatic,Subversion (SVN). Varje dag har den kod som uppdaterats skickats in till systemet tillsammans med en beskrivning av vad som gjorts. Detta har visats sig användbart för att hitta orsaker till införda fel.
38 KAPITEL 5. GENOMFÖRANDE OCH RESULTAT
5.2.2 LPC2292
För att skriva koden till LPC2292 användesµVision3 från Keil. Utvecklingsmiljön har bra stöd för avlusning av kod. Tillsammans med en JTAG ulink2, också den från Keil, kunde brytpunkter och stegning användas under körning. JTAG användes vanligtvis för att ladda ned mjukvaran till mikrokontrollern, men ibland användes ett program för installation över serieporten, utvecklad av Plockmatic. När den egna mjukvaran för nedladdning började fungera användes vanligen den. Med JTAG finns hela adressrymden tillgänglig, och med hjälp av Dissasembly
Mixed mode är det möjligt att avgöra exakt var i minnet instruktioner är lagrade.
Eftersom programmet kopierar kod från Flash till RAM och exekverar där så försvinner möjligheten att se exakt vilken kod som körs när programmet är i RAM. Men på grund av att samma kod finns iMixed mode i Flash är det trots allt möjligt att lista ut vad det är som körs. Om ett fel uppstår finns felmeddelanden, det är då möjligt att ta reda på vad som gått snett, till exempel att en ogiltig adress använts. Det finns även en extra UART-port som använts för utskrifter till ett terminalfönster. Det har varit ett bra komplement till JTAG vid vissa tillfällen. Utvecklingsmiljön har underlättat utvecklandet mycket.
5.2.3 M16C
Utvecklingsmiljön som användes för att skriva till M16C var Visual Studio 2005 från Microsoft. Det gav visst stöd för färgning av syntax och möjlighet att se variabeltyper. För att kompilera och länka användes .bat-skript och för att lad-da ned till mikrokontrollerna användes mjukvara från Plockmatic för nedladdning över serieporten. När de egna programmen började fungera användes även de för installation av ny mjukvara. De möjligheter för avlusning som fanns var att blin-ka två LEDar och skriva ut på en extra UART-port. För att underlätta avlus-ning skrevs rutiner som skickade hela eller delar av innehållet i RAM och Flash över UART-porten. För att hantera större datamängder användes det kraftfulla terminalprogrammet Realterm. Terminalprogrammet användes även i början för att skicka data från .mot-filer.
5.2.4 PC
5.3. SKILLNADER I HÅRDVARA 39
På så vis går det till exempel att verifiera att data lästs in från filer på ett korrekt sätt.
5.2.5 CAN
För att kunna avgöra vad som skickas på CAN-bussen har en så kallad »CAN-lyssnare« använts. Det är en USB till CAN-adapter som används med mjukvara utvecklad av Plockmatic. Det finns möjlighet att filtrera, namnge och färglägga meddelanden på CAN-bussen så det tydligt går att följa vad som händer. Det går även att skicka meddelanden.
5.3 Skillnader i hårdvara
Under utvecklingsarbetet har det framkommit att det finns olika versioner av de mikrokontrollermodeller som Plockmatic använder. De skillnader som finns re-dovisas här.
5.3.1 M16C
Vissa kort har istället för M16C/6NA versionen M16C/6N4. Det som skiljer dem åt och påverkar uppgradering är hur data ska skrivas till Flash. Den ena versionen kräver att data skrivs 256 byte i ett svep medan den andra fodrar skrivning av 2 byte i taget [26]. Därför behöver koden ta hänsyn till vilken version av kontroller den exekveras i. Det går inte att veta i förväg vilken version av mikro-kontroller det rör sig om, så koden måste kunna känna av skillnaden och anpassa sig. Detta åstadkommes med hjälp av ett register, Flash Memory Control Register 0 (FMR0). Registrets adress skiljer sig åt mellan de två versionerna. Genom att kontrollera värdet på adresserna kan mikrokontrollern avgöra vilken version koden exekveras i.
5.3.2 LPC2292
Det finns uppdaterade versioner av mikrokontrollern från NXP. Dessa skiljer sig åt vid initieringen av CAN. Originalversionen och efterföljaren /00 fungerar på samma sätt, medan/01 kräver annan kod. Eftersom kontrollerna skiljer sig åt på ett sätt som redan påverkar Plockmatic finns färdig kod för att skilja versionerna åt.
40 KAPITEL 5. GENOMFÖRANDE OCH RESULTAT
5.4 Kommunikation
Här redogörs för RS232 och det meddelandeprotokoll som utvecklats. Det här examensarbetet ska svara på frågorna:
3. Vad finns det för begränsningar i det system Plockmatic använder?
4. Vilket protokoll ska användas för uppdatering?
5.4.1 RS232
De kretskort som har M16C är utrustade med en extern klocka på 16 MHz. Med den klockfrekvensen är den maximala hastigheten på UART-porten 57600 Baud. Med extern UART-klocka kan upp till 5 MBaud användas. Kretskorten är utrustade med en port för bland annat extern UART-klocka. På den vägen är det möjligt att öka överföringshastigheten. Detta har dock inte gjorts på grund av att det då behövs en ny sladd till varje servicetekniker. Plockmatic vill minimera förändringen som krävs för att genomföra en centraliserad uppgradering. Projektet är nu utfört så att uppgraderingen går att genomföra med samma utrustning som används vid nuvarande uppgraderingar.
RS232 har som beskrevs i 2.3 stöd för paritet. Eftersom paritet trots sitt sva-ga skydd är bättre än inget så är det aktiverat. Versionen som används är udda paritet, det vill säga antalet ettor är alltid udda. Kommunikationen sker med 8 bitar per byte. Eftersom stoppbiten har en längd på en bit och paritet är aktiverat får en byte en total längd på 11 bitar inklusive startbit. För att få en uppfattning om hur mycket tid mikrokontrollerna har till förfogande att hantera ett inkom-met meddelande innan nästa är färdigt gjordes följande uträkningar. M16C valdes eftersom det är den långsammare av de två mikrokontrollermodellerna. Exekver-ingstiden är enligt manualen på 62, 5ns/instruktion för de kortaste instruktionerna vid 16 MHz [10]. Med en överföringshastighet på 57600 Baud blir tiden för att ta emot en Byte 5760011 ≈ 1, 91 · 10−4 s/Byte. Antalet kortast möjliga
instruktion-er som mikrokontrollinstruktion-ern kan exekvinstruktion-era undinstruktion-er tiden det tar att ta emot en Byte blir då 1,91·1062,5·10−4−9 = 3056instruktioner/Byte. Antalet borde teoretiskt räcka för att göra
5.4. KOMMUNIKATION 41
5.4.2 Meddelandeprotokoll
För att kunna skicka data utvecklades ett meddelandeprotokoll som förenar de fysiska protokollen RS232 och CAN. Varje RS232-meddelande är anpassat att lätt kunna konverteras till ett CAN-meddelande. I tabell 5.1 visas hur ett meddelande ser ut och hur det passar in i ett CAN-meddelande. Kommunikationen på RS232 sker som nämndes i 5.4.1 ovan med 8 bitar data per Byte, vilket passar bra in i CAN-meddelandet och även är den storlek på Bytes som båda mikrokontroller-na använder. Meddelandet är anpassat för en identifierare på 11 bitar. För att använda meddelandet med den längre identifieraren på 29 bitar krävs endast att två extra Bytes infogas efter Byte 5 samt att två eller tre bitar tillfogas till Byte 5. Den längre identifieraren hör till CAN extended mode och används på Plock-matics XCAN-buss. I det här projektet har dock endast den kortare identifieraren använts. Bara de fem lägsta bitarna används för identifiering, de övre används för att karaktärisera meddelandetypen. Detta medför att endast 31 stycken unika identifierare kan finnas på en ICAN-buss.
RS232 CAN
1. StartByte 1 (0xAA)
2. StartByte 2 (0xFF)
3. StartByte 3 (0xCC)
4. CAN-identifierare, bit 0-5 CAN-identifierare
5. CAN-identifierare, bit 6-10
6. Antal Bytes som följer Data Length Code
7. Räknare Data 1 8. Meddelandetyp Data 2 9. Data Data 3 10. Data Data 4 11. Data Data 5 12. Data Data 6 13. Data Data 7 14. Data Data 8
Tabell 5.1: Det nya meddelandeprotokollet. Till vänster syns meddelandet på RS232-linan, och till höger hur det passar in på CAN.
De tre första Bytes som skickas över RS232 har endast syftet, att hjälpa motta-garen att hitta början av meddelandet. Orsaken till att det är tre Bytes är att sannolikheten att ett fel uppstår minskar med varje ny startByte. Med en start-Byte är sannolikheten att mottagaren tar fel 1/256, vid slumpmässig data. Vid
flera startBytes i följd multipliceras sannolikheterna med varandra, tre Bytes ger
1/2563. Tre Bytes valdes för att sannolikheten att de tre uppträder som en falsk
42 KAPITEL 5. GENOMFÖRANDE OCH RESULTAT
Ett alternativ till att ha startBytes är att skicka allt med ASCII-representation. Vid ASCII-representation skickas varje Byte som två ASCII-tecken. Till exempel skickas 0x5A som tecknen »5« (0x35) »A« (0x41). På grund av att det finns teck-en utanför dteck-en rymd som används för att represteck-entera datan kan ett startteckteck-en istället användas. Dock behövs många fler Bytes för att skapa ett meddelande. Med en startByte och två tecken per Byte för de 11 i meddelandet i tabell 5.1 behövs 1 + 11 · 2 = 23 Bytes. Med tre startBytes sparas 23 − 14 = 9 Bytes per meddelande och överföringstiden minskas med 39%. En annan orsak till att inte använda ASCII är att det krävs mer beräkning i den mikrokontroller som agerar brygga till CAN-bussen. Med mer beräkning finns risk att ett tecken inte hinner beräknas och därför skrivs över. Om synkroniseringen tappas finns mekanismer för att lösa problemet i både PC och mikrokontroller. Mer om det i 5.6.2.
DataByte ett och två i CAN-meddelandet används alltid, därmed varierar antalet dataBytes mellan två och åtta. Den första Byten är en räknare. Till räknaren adderas 1 för varje nytt meddelande. När räknaren når 255 får den vid nästa addering »slå runt«, det vill säga bli noll igen. Antalet 255 är det största värdet som kan uppnås med 8 bitar. Den andra dataByten i CAN-meddelandet och Byte 8 i RS232-meddelandet är meddelandetypen. Den avgör om de Bytes som följer till exempel är en adress i Flashminnet, data eller en begäran om omsändning på grund av fel. Det har skapats 9 meddelandetyper som används i kommunikationen. De visas i tabell 5.2. Det som skiljer de sista tre meddelandena är att de används för att synkronisera kommunikationen.
FLASH_ADDRESS_MESSAGE 0x01 SOFTWARE_MESSAGE 0x02 START_BRIDGE_MESSAGE 0x03 SOFTWARE_FINISHED_MESSAGE 0x04 UPGRADE_NEEDED_MESSAGE 0x06 NO_MORE_DATA_MESSAGE 0x08 MESSAGE_START 0x21 MESSAGE_RESEND 0x22 BLOCK_RESEND 0x23
Tabell 5.2: Meddelandetyper som används i kommunikationsprotokollet.
5.5 Initiering
5.5. INITIERING 43
5. Hur ska persondatorn fysiskt kopplas in i styrsystemet?
6. Fungerar en nod i systemet som ladd-master vid nedladdningen?
7. Hur hanteras Flashminnet med bootblock och sektorer?
8. Hur hämtar persondatorn mjukvaruversionerna på kretskorten för att säker-ställa att rätt version laddas ned?
9. Kan felkoder och räknare hämtas från maskinen samtidigt som mjukvaran uppdateras?
5.5.1 Inkoppling
Innan uppgraderingen kan börja behöver PCn kopplas ihop med maskinen. Detta sker genom att uppgraderingssladden kopplas in på det kort som agerar som mas-ter i maskinen. Vid traditionell uppgradering kopplas två kontakmas-ter in på korten, den ena för att överföra data och den andra för att försätta hårdvaran i installa-tionsläge. Eftersom det här projektet går ut på att skriva egen kod som installerar över CAN-bussen och inte använda de inbyggda installationsfunktionerna kopplas bara kontakten för överföring av data in. Kortet som agerar styrkort vid vanlig drift är även det som används som ladd-master.
5.5.2 Mjukvaruversion och räknare
I en maskin finns alltid samma antal mikrokontroller och de har alltid standard-iserade identifierare på CAN-bussen. Det som kan skilja mikrokontrollerna åt är mjukvaruversionen. Därför har det i PCns program i skapats en tabell där tillgäng-lig mjukvaruversion kopplas till CAN-id. Innan uppdateringen börjar kontrollerar programmet vilka mikrokontroller som är i behov av att uppgraderas. I Plockmat-ics maskiner finns tillgängliga meddelanden för förfrågan om mjukvaruversion. De meddelandena har implementerats i koden för mikrokontrollerna. PCn skickar först en begäran om att ladd-mastern ska gå in i bryggläge. Därefter frågar den i tur och ordning varje nod vilken mjukvaruversion som är installerad. Det installerade ver-sionsnumret jämförs med det tillgängliga i datorn. Om den tillgängliga versionen är senare än den installerade läggs CAN-identifieraren i en lista över vilka noder som ska installeras. När den sista mikrokontrollern har svarat vet programmet i PCn vilka som ska uppgraderas och följaktligen vilka filer som behöver öppnas och bearbetas.
44 KAPITEL 5. GENOMFÖRANDE OCH RESULTAT
det endast standardiserade meddelanden för att hämta totalräknare över XCAN. Eftersom felkoderna är tillämpningsberoende varierar de mellan maskiner, och det finns inte ett standardiserat sätt att hämta dem. Det är dock möjligt att skapa funktioner för utläsning och skicka de räknare och felkoder som finns för att visa på persondatorns skärm. Detta har inte gjorts i examensarbete.
5.5.3 Datafiler
För att hantera informationen i datafilerna har två nya objektstyper skapats, softwareContainer och RS232_Message. Det första objektet används för att la-gra all data från en fil i minnet. Objektstypen innehåller en lista för adresser i Flashminnet och en lista för data som ska lagras på respektive adress. I .hex och .mot-filerna som datan lagrats i från början finns det en adress per 16 Byte. I ob-jektet softwareContainer finns en adress per 256 Byte. Detta för att passa med hur mikrokontrollerna skriver data till Flash. I datafilerna kan det finnas luckor av olika slag som gör att datan inte är kontinuerlig. Eftersom data måste skrivas komplett i multiplar om 256 Byte måste luckorna fyllas med tom data. Om det rör sig om en.mot-fil fylls luckor med 0xFF (255), vilket är det värde som den tomma luckan skulle få vid vanlig installation. Om det är en.hex-fil fylls data i mitten av filen med 0x00 (0) men i slutet med 0xFF (255). Detta för att imitera resultatet av vanlig installation. 0xFF är det värde raderad Flash får, och att fylla ut med det värdet i slutet får det att verka som regionen är orörd. Antalet adresser får vara ojämnt om det är en .mot-fil, men måste vara jämnt om det är en .hex-fil. Detta har att göra med att M16C skriver 256 Bytes i taget och LPC2292 512 Bytes i ett svep. Programmet ser till att fylla på med ett tomt block med data om så krävs för att mikrokontrollern ska kunna skriva.
LPC2292 har även ett krav på koden för att starta. Mikrokontrollerns boot-sektor räknar samman alla de interruptvektorer som är placerade i början av Flash. Koden godkänns endast om resultatet är noll. Annars startar inte mikrokontrollern. För att resultatet ska bli noll ska den plats som finns på adresserna 0x14-0x17 inne-hålla tvåkomplementsvärdet av de andra vektorerna [9]. Uträkning av detta sköts inte automatiskt vid kompilering och länkning utan måste göras vid inläsning av filen. När hela filen har behandlats läses och adderas de vektorer som finns och två-komplementet på summan beräknas. Tvåtvå-komplementet motsvarar en total invers och kommer göra så att summan blir noll. Resultatet lagras i softwareContainer-objektet på rätt plats.
