INOM
EXAMENSARBETE ELEKTROTEKNIK, GRUNDNIVÅ, 15 HP
STOCKHOLM SVERIGE 2020,
Fjärruppdatering i ett CAN-nätverk Remote update in a CAN-network
Glöm inte att du alltid CAN
HENRIK SELLÉN WIKSTRÖM MAGNUS ROOS
KTH
SKOLAN FÖR KEMI, BIOTEKNOLOGI OCH HÄLSA
Fjärruppdatering i ett CAN-nätverk
Remote update in a CAN-network
MAGNUS ROOS
HENRIK SELLÉN WIKSTRÖM
Examensarbete inom elektroteknik Grundnivå, 15 hp
Datum: 8 juni 2020
Handledare på KTH: Torgny Forsberg Examinator: Elias Said
TRITA-CBH-GRU-2020:071 KTH
Skolan för kemi, bioteknologi och hälsa 141 52 Huddinge, Sverige
Fjärruppdatering i ett CAN-nätverk
c
2020 Magnus Roos och Henrik Sellén Wikström
Sammanfattning | i
Sammanfattning
Controller Area Network(CAN) är ett väletablerat, robust, meddelandebaserat protokoll som tillsammans medSociety of Automotive Engineers(SAE) J1939 standard används det till kommunikation och dataöverföring i tunga fordon och industrier. Noderna i ett sådant nät sitter oftast svårtåtkomliga för direkt fysisk tillgång vilket gör uppdateringsprocessen av mikrokontrollern svår att genomföra.
Målet med arbetet har varit att ta fram en lösning som möjliggör mjukvaru- uppdatering via CAN i ett redan etablerat nätverk. Den här rapporten ger en teknisk genomgång av CAN och standarden J1939 samt en mikrokontrollers bootloader och dess minnesuppbyggnad, mer specifikt en ATmega328p.
Arbetet resulterade i ett uppdateringsverktyg och en anpassad bootloader.
Uppdateringsverktyget kan läsa en Intel Hex-fils data och skicka den till en mikrokontroller via CAN. Modifiering av bootloadern innebar att den kunde ta emot uppdateringen via CAN och genomföra skrivningen till program- minnet. Överföringen sker med hjälp av transportprotokollet specificerat i standarden J1939-21 och mjukvaruuppdateringen verifieras med hjälp av Cyclic Redundancy Check. För att garantera att uppdateringsprocessen inte överstiger den tidsgräns som angivits i kraven genomfördes tester med olika överföringshastigheter och uppdateringsstorlekar.
Nyckelord
Controller-Area-Network, J1939, SocketCAN, bootloader, ATmega328p, inbyggda system, Python, flashminne
ii | Sammanfattning
Abstract | iii
Abstract
Controller Area Network (CAN), is a well established, robust communication protocol which, in combination with Society of Automobile Engineers (SAE) J1939 standard, is frequently used for data transfer in heavy duty vehicles and industries. In many applications the nodes are located in places which are hard to reach which can make the firmware update process difficult to accomplish.
The goal with this project was to create a method to perform firmware update of a node in a established CAN network. This report offers a technical description of CAN, J1939, bootloader and the memory structure of an ATmega328p microcontroller.
The project resulted in a modified bootloader which can receive a firmware update from CAN, write it to the flashmemory and verify the data integrity by calculating Cyclic Redundancy Check. A flashtool was created to handle the update process and it uses a Intel Hex file as input for the firmware data. To guarantee that the update process does not exceed the time limit, tests were made with various transmission rates and update sizes.
Keywords
Controller-Area-Network, J1939, socketCAN, bootloader, ATmega328p, em- bedded systems, Python, flash memory
iv | Abstract
INNEHÅLL | v
Innehåll
1 Inledning 1
1.1 Problem . . . 1
1.2 Mål . . . 2
1.3 Avgränsningar . . . 3
2 Bakgrund och teori 5 2.1 Tidigare arbeten . . . 5
2.2 Controller Area Network . . . 5
2.2.1 CAN-nätverket . . . 7
2.2.2 Filter och masker . . . 8
2.2.3 SAE J1939 . . . 9
2.3 Bootloader. . . 13
2.3.1 Minnesarkitektur . . . 14
3 Metoder 17 3.1 Litteraturstudie . . . 17
3.2 Bootloader. . . 18
3.2.1 Val av bootloader . . . 18
3.2.2 Inträdesvilkor till bootloadern . . . 19
3.3 Kommunikation med CAN . . . 20
3.3.1 Filter och masker . . . 20
3.3.2 Virtualisera CAN . . . 21
3.4 Hårdvara och tester . . . 21
4 Resultat 23 4.1 SAE J1939 PGN:s . . . 23
4.1.1 Filter och masker . . . 23
4.2 Modifiering av bootloader . . . 24
4.3 Programutveckling för mikrokontroller . . . 26
4.3.1 Koden i applikationsminnet . . . 26
vi | Innehåll
4.3.2 Implementering av CAN i bootloader . . . 27
4.4 Uppdateringsverktyget . . . 29
4.5 Verifiering av mjukvarudata . . . 30
4.6 Uppdateringsprocessen . . . 31
4.6.1 Fas 1 – Initiering . . . 31
4.6.2 Fas 2 – Överföring . . . 32
4.6.3 Fas 3 – Verifiering . . . 32
4.6.4 Fas 4 – Avslut . . . 33
4.7 Tester . . . 34
5 Analys och diskussion 35 5.1 Sändningsfönter . . . 35
5.2 Parameter Gruppnummer . . . 36
5.3 Optimering av mjukvarukod . . . 36
5.4 Uppdateringsmetoder . . . 37
5.5 Återhämtning vid fel . . . 37
5.6 Hållbar utveckling och etik . . . 37
6 Slutsatser 39 Referenser 41 A SAE J1939 43 A.1 Proprietary A . . . 43
A.2 Acknowledge . . . 44
A.3 Antal möjliga PGN:s . . . 45
B Uppdateringsverktyget 46 B.1 Argument vid körning. . . 46
Lista på akronymer och förkortningar | vii
Lista på akronymer och förkortningar
ACK Acknowledge
CAN Controller Area Network CRC Cyclic Redundancy Check CTS Clear To Send
DA Destination Address DP Data Page
EDP Extended Data Page
EEPROM Electrically Erasable Programmable ROM GE Group Extension
ICSP In Circuit Serial Programming
ISO-TP ISO Standard 15765-2 transport protocol MCUSR Mikrokontrollerns Status Register NRWW No-Read-While-Write
PA Proprietary A
PDU Protocol Data Unit PF PDU Format
PGN Parameter Group Number PS PDU Specific
RTR Remote Transmission Request RTS Request To Send
RWW Read-While-Write
viii | Lista på akronymer och förkortningar
SA Source Address
SAE Society of Automotive Engineers SPI Serial Peripheral Interface
SPN Suspect Parameter Number
TP.CM Transport Protocol Connection Management TP.DT Transport Protocol Data Transfer
USF Uppdateringsstatusflaggan
Inledning | 1
Kapitel 1 Inledning
Som följd av den tekniska utvecklingen har möjligheterna öppnats för att implementera mikrokontroller i alla tänkbara produkter. Applikationen som körs på mikrokontrollern kan laddas upp antingen med hjälp av särskilda verktyg som är kostsamma och kräver särskild kompetens eller genom att låta mikrokontrollern innehålla en bootloader som skriver applikationen till minnet[1]. Båda metoderna kräver fysisk tillgång till mikrokontrollern och när den används i till exempel ett fordon är det vanligt att dess placering försvårar uppdateringen.
Det här examensarbetet ämnar att utveckla en metod för att på distans kunna uppdatera mjukvaran på en mikrokontroller. Examensarbetets uppdragsgivare har olika sensorer monterade på en båt där kommunikationen sker med hjälp av mikrokontroller uppkopplat i ettController Area Network(CAN) där det i dagsläget enbart finns möjlighet att uppdatera mjukvaran med direkt anslut- ning via USB. CAN-protokollet är ett väletablerat, robust meddelandebaserat protokoll som används i olika typer av elektriska system för fordon samt i industrier och arbetet kan därför komma att intressera ingenjörer inom elektroteknik.
1.1 Problem
För att möjliggöra mjukvaruuppdatering av mikrokontroller i ett CAN-nätverk har två problemområden identifierats: (1) stöd för mjukvaruuppdateringar genom CAN i noderna och (2) ett programverktyg som kan sända mjukvaru- uppdateringen till en nod i nätverket.
2 | Inledning
(1) Stöd i noderna för mjukvaruuppdateringar via CAN
• Noderna använder en Arduino för bearbetning av mätvärden och kom- munikation ut på CAN-bussen. Under en mjukvaruuppdatering behöver data både skrivas och läsas från flashminnet. Om det inte finns stöd för det, vad finns det för metoder för att lösa det?
• Vid mjukvaruuppdatering är det centralt att bootloadern inte skrivs över.
Hur ska minnet partitioneras för att skydda bootloadern?
(2) Programverktyg för sändning av mjukvaruuppdatering
• Programverktyget som ska hantera mjukvaruuppdatering ska skrivas i Python. Finns det stöd för att hantera mjukvaruppdateringsformatet på ett tillfredsställande sätt?
• CAN-meddelanden har en maxstorlek på 8 byte. Hur möjliggörs över- föring av data som större än 8 byte?
• Hur säkerställer man att dataintegriteten bibehålls vid en mjukvaru- uppdatering, dvs att uppdateringsdata förblir oförändrat under data- överföring och datalagring?
1.2 Mål
Målet med arbetet är att undersöka möjliga metoder för att genomföra mjukvaru- uppdatering av en specifik nod i ett CAN-nätverk. Den bäst lämpade metoden ska implementeras och resultera i en slutprodukt som består av två delar:
Mjukvara till noderna som möjliggör mjukvaruuppdatering via CAN och ett verktyg som används för att administrera uppdateringsprocessen.
Uppdragsgivaren har preciserat ett antal krav på den slutgiltiga produkten.
Kraven utgör därför delmål för arbetet vilka är följande:
• Kommunikation ska ske med nätverksprotokolletSAEJ1939;
• Tidsåtgången för mjukvaruuppdatering får inte överstiga två minuter;
• Mjukvaruuppdateringens dataintegritet ska kunna verifieras, exempel- vis genomCRC.
Inledning | 3
• Uppdateringsverktyget ska:
– vara skrivet i Python och använda sig av socketCAN;
– kunna läsa Intel HEX-filer från Arduino IDE;
– kunna välja vilken nod i nätverket som ska uppdateras.
• Mikrokontrollern:
– Nod ID ska lagras iEEPROM.
– Hårdvarustöd ska finnas för MCP2515, TJA1050 och ATmega328p.
– Helst ska den gamla bootloadern finnas bredvid den nya för att även i fortsättningen kunna uppdatera via USB.
1.3 Avgränsningar
J1939 innehåller många standarder och definitioner för tillämpning och använd- ningsområden. Den enda delen som kommer användas i detta arbete är J1939-21. Dokumenten för standarden är reviderade december 2010. Det är inte den senast reviderade versionen utgiven avSAEInternational och arbetet kommer inte undersöka skillnader mellan de olika versionerna. Dessutom kommer implementationen av J1939 endast ha stöd för de funktioner och Parameter Group Number (PGN) som krävs för att genomföra en mjukvaru- uppdatering.
4 | Inledning
Bakgrund och teori | 5
Kapitel 2
Bakgrund och teori
Det här kapitlet börjar med ett tidigare relaterat arbete och är därefter uppdelat i två delar. I den första delen beskrivs CAN-protokollet, CAN-nätverket från uppdragsgivaren och de olika delarna som används inom CAN-kommunikation för arbetet. Den andra delen beskriver mikrokontrollern som används i en nod, hur dess minne fungerar och hur den uppdaterar sin mjukvara genom en bootloader.
2.1 Tidigare arbeten
P.T Karule och P. Selokar utvecklade en bootloader för att stödja mjukvaru- uppdateringar som sänds med UART-protokollet. För att garantera data- integriteten var mikrokontrollens flashminne uppdelat i tre sektorer: boot- loader, master och sekundär. Vid en mjukvaruuppdatering genomfördes den initiala skrivningen av nya applikationen till sekundärregionen, som inte in- nehöll den aktuella applikationen. Efter att datan i sekundärsektorn verifierats skrevs den till mastersektorn [2].
2.2 Controller Area Network
CAN-protokollet är ett robust meddelandebaserat protokoll som finns defini- erat i standarden ISO 11898 och används idag framförallt inom fordon, automation och industrier. Standarden specificerar CAN för lager 1 och 2 i OSI-modellen; högre lager lämnas till användare att implementera. Exempel- vis används Onboard Diagnostic (OBD) inom bilindustrin i verktyg för att lokalisera problem i bilar och har specifikationer för lager 3 och 4. Den fysiska bussen består av två ledningar — CAN hög och CAN låg — där strömmen
6 | Bakgrund och teori
går i varsin riktning och bidrar till att skillnaderna på signalerna elimineras.
Detta gör protokollet väl anpassat till miljöer med mycket störning, t.ex. bilar, båtar och tunga fordon samt industrier. CAN-protokollet använder sig också av omsändning av meddelande och verifiering av dess integritet genomCyclic Redundancy Check(CRC).
En nod i ett CAN-nät består av minst en kontroller och en transceiver för att kunna kommunicera. Transceivern arbetar på det fysiska lagret och omvandlar signalerna på CAN-busen åt kontrollern; den blir på så sätt ett gränssnitt mellan CAN-protokollet och den fysiska bussen. Kontrollern står själv för implementeringen av CAN-protokollet med CAN ID, mask och filter samt mottagnings- och sändningsbuffert. Den arbetar framförallt på lager 2 i OSI- modellen. Ett nät av anslutna CAN-noder kan ses i figur2.1.
Figur 2.1 – Noder anslutna i ett CAN-nätverk, anslutna till varsin mikro- kontroller
Adressering CAN räknas som ett broadcastprotokoll vilket innebär att varje nod i ett CAN-nätverk tar emot samtliga meddelanden. Den innehåller ingen mottagar- eller sändaradress utan använder sig av ett identifieringsnummer
Bakgrund och teori | 7
som symboliserar vad meddelandet avser. Noderna använder filter för att enbart hantera meddelanden de vill ta del av.
CAN-ram Ett meddelande, även kallat ram (frame), kan vara en standard ram definierad i CAN2.0A eller utökad ram (CAN2.0B). Identifieringsnumret består av 11 bitar i en standard CAN-ram och 29 bitar i en utökad ram. Se figur 2.2respektive figur2.3.
Figur 2.2 – En standard CAN-ram som använder 11 bitars identifikation.
Figur 2.3 – En utökad CAN-ram som använder 29 bitars identifikation.
2.2.1 CAN-nätverket
CAN-nätverket består av flera anslutna noder samt en anslutningspunkt där en dator kan kopplas in med hjälp av en CAN-adapter. Varje nod består av en MCP2515 CAN-modul, utvecklingskortet Arduino Nano och någon form av sensor eller styrenhet. Nätverkets topologi kan ses i figur2.4.
CAN-modul MCP2515 är uppbyggd dels av en CAN-transceiver av typen TJA1050 [3] och dels av en CAN-kontroller av typen MCP2515 som om- vandlar meddelanden enligt CAN 2.0b-specifikationerna (ISO 11898) [4].
CAN-kontrollern kommunicerar med en mikrokontroller genomSerial Perip- heral Interface (SPI) med en maximal hastighet på 10MHz. Ytterligare har kontrollern tre sändningsbuffertar och tre mottagarbuffertar som kan läsas och skrivas till.
8 | Bakgrund och teori
Figur 2.4 – CAN-nätverk med noder.
SocketCAN är ett applikationsprogrammeringsgränssnitt (API) för CAN- protokollet, ursprungligen utvecklat av Volkswagen som ingår i Linux kernel sedan version 2.6.25. Det är designat att efterlikna TCP/IP-socketprogrammering för att underlätta användning inom mjukvaruutveckling. Det ger möjlighet att kommunicera över CAN med hjälp av en adapter alternativt genom ett virtuellt gränssnitt [5].
2.2.2 Filter och masker
Filter och masker kan användas i CAN-kontrollern för att filtrera bort CAN- ramar redan innan de bearbetas i applikationen och kan därför spara processor- kraft, kodstorlek i flashminnet etc. Meddelanden filtreras baserat på CAN ID där masker används för att bestämma vilka bitar i ID:t som måste matcha filtrets bitar; principen ses i sanningstabellen 2.1. Ett annat sätt att beskriva filtrering av CAN-meddelande är att meddelande som inte uppfyller följande villkor kommer avfärdas:
(mottaget can id) & mask == filter & mask
Enligt databladet för MCP2515 [4] (sida 33) tas nya meddelanden emot och laddas upp i mottagningsbufferten Message Assembly Buffer (MAB). Där jämförs meddelandets CAN ID mot de filter som finns konfigurerade. Om ett ID accepteras av filtret laddas meddelandet in i en av de två mottagnings-
Bakgrund och teori | 9
Mask bit Filter bit Message ID bit Resultat
0 * * Acceptera
1 0 0 Acceptera
1 0 1 Avvisa
1 1 0 Avvisa
1 1 1 Acceptera
Tabell 2.1 – Filter/mask sanningstabell
buffertar som finns och kan sedan avläsas från de register som tillhör bufferten.
SocketCAN implementerar mask och filter i mjukvara och har utvecklats för att efterlikna CAN-hårdvarufilter men använder också de tre mest signifikanta bitarna i det 32-bitars heltalet som ID:t lagras i. Detta är en metod för att kunna särskilja om meddelandet har ett standard ID eller utökat ID, om det är av typen Remote Transmission Request(RTR) eller ERROR-ram. Detta brukar annars hanteras av hårdvara. I kodavsnitt 2.1 ses ett utdrag ur headerfilen can.h från socketCAN som visar de olika flaggor och masker som kan användas tillsammans med CAN-ID:t.
/* special address description flags for the CAN_ID */
#define CAN_EFF_FLAG 0x80000000UL /* EFF/SFF is set in the MSB */
#define CAN_RTR_FLAG 0x40000000UL /* remote transmission request */
#define CAN_ERR_FLAG 0x20000000UL /* error message frame */
/* valid bits in CAN ID for frame formats */
#define CAN_SFF_MASK 0x000007FFUL /* standard frame format (SFF) */
#define CAN_EFF_MASK 0x1FFFFFFFUL /* extended frame format (EFF) */
#define CAN_ERR_MASK 0x1FFFFFFFUL /* omit EFF, RTR, ERR flags */
Kodavsnitt 2.1 – Fördefinerade masker och flaggor från socketCAN
2.2.3 SAE J1939
J1939 är en samling av standarder framtagen av Society of Automotive Engineers(SAE) som beskriver hur data ska överföras mellan noder i ett CAN- nätverk. I OSI-modellen definieras lager 2 (datalänk), lager 3 (nätverk), 4
10 | Bakgrund och teori
(transport) och 7 (applikation); CAN-protokollet används för lager 1 (fysiska) och 2 (datalänk). Den delen som beskriver datalänklagret är J1939-21, och använder sig av utökade CAN-ramar på 29-bitar.
CAN-ramar kallas förProtocol Data Unit(PDU) och består av sju fördefinie- rade fält och informationen de innehåller bestäms på applikationslagret (lager 7). Fälten är Priority, Extended Data Page, Data Page, PDU Format, PDU Specific,Source Addressoch ett datafält med 0 till 8 bytes precis som i CAN- protokollet, se figur2.5.
Figur 2.5 – J1939 ramformatet. P är priority, EDP är Extended Data Page, DP är Data Page, PF är PDU-format, PS är PDU Specific och SA är Source Address.
Priority används för att ge meddelanden förtur på sändningar. De tre bitarna maskas bort av mottagaren. Högsta prioritet är 0 och lägsta 7. Standardvärdet för alla kontrollmeddelanden är 3 (0112) och för proprietary, request och ACK är det 6 (1102).
Extended Data Page(EDP) ochData Page(DP) används för att bestämma strukturen på ID:et för datafältet i CAN-ramen. Datapagebiten bestämmer om meddelandet ska vara Page 0 eller 1 i Parameter Group Number template. Om extended page är 1 är CAN-meddelandet definierat som reserverat av SAE J1939 eller som en del av standarden ISO-15765-3 [6] och kommer därför i detta arbete alltid vara 0. SOF, SRR, IDE,RTR, delar av control field, CRC, ACK och EOF fälten är definierat av CAN-protokollet och modifieras inte av J1939.
PDU Format (PF) är ett 8-bitars fält och bestämmer formatet på PDU:n.
Ett värde påPFmellan 0 och 239 ger formatet PDU1 ochPS-fältet räknas då
Bakgrund och teori | 11
som meddelandets destinations adress. PDU1 kan endast skickas till specifika adresser med undantaget för adressen FF16, vilket är en global adress som alla J1939-noder måste lyssna och svara på. En PF mellan 240 och 255 ger formatet PDU2 och kan endast skickas som globala meddelanden.PS-fältet är då en utökning av möjligaParameter Group Number(PGN) så kalladGroup Extension(GE).
PDU Specific (PS) är ett 8-bitars fält och beroende av PF-fältet för defini- tion. Vid PDU1-format är PS en destinationsadress och PDU2-format är en Group Extension(GE).
Source Address(SA) är ett 8-bitars fält som innehåller meddelandets käll- adress.
Parameter Group Number
J1939 använder sig av PGN för att identifiera vilken sorts information med- delanden innehåller. En PGN representerar en eller flera Suspect Parameter Number(SPN). Till exempel finns en PGN för meddelanden som kontrollerar dörren i en bil och ett av de tillhörande SPN:s är att styra sidospegeln.PGN kan även stå för olika meddelandetyper som kan skickas till noder, t.ex.
kommandon, förfrågningar, kvitteringar etc. Det finns även PGN som används till meddelande för J1939:s transportprotokoll som används för överföringar av data som inte ryms i en CAN-ram.
PGN är enligt J1939-21 ett 18-bitars tal som sträcker sig frånEDP-biten till PS-fältet [6]. MSB:n i numret är 1 bit extended data page följt av 1 bit data page, 8 bitar PDU format. De sista 8 bitarna,PS-fältet, är alltid 0016omPFär mindre än 240, annars räknas det värdet en del av Group Extension (GE). När enPGNskickas i datalasten räknas det som ett 24-bitars tal där de 6 MSB är satta till 0.
Totala antalet möjliga PGN är begränsat till 8672, se ekvationA.1i appendix A. De flesta är också redan definierade av J1939 och anpassade för användning inom fordon och industrier. Det finns dock tre PGN:s som är menade för utvecklare, användare och företag att definiera själva, de kan ses i tabell2.2.
12 | Bakgrund och teori
Namn Parameter Group Number Proprietary A 61184 (00EF0016)
Proprietary A2 126720 (01EF0016)
Proprietary B 65280 till 65535 (00FF0016till 00FFFF16)
Tabell 2.2 – De tre PGN:s reserverade för utvecklare, användare och företag att definiera. Proprietary B är en Group Extension och använder även PDU specific-fältet.
Dataöverföring
CAN-meddelanden kan som mest innehålla 8 bytes av data och för att åstad- komma större överföringar har J1939-21 skapat funktioner för ett transportpro- tokoll som en del av datalänklagret. Funktioner som används är uppdelat i två huvudugrupper: meddelandepacketering och återmontering samt hantering av anslutning.
Packetering och återmontering kallas Transport Protocol Data Transfer (TP.DT) med PGN 60416. Ett meddelande innehåller sekvensnummer på 1 byte och 7 bytes av datan som ska skickas. Om det är det sista paketet i överföringen och data som skickas är mindre än 7 bytes fylls oanvända bytes med FF16.
Hantering av anslutningen sker med meddelande som kallas Transport Protocol Connection Management(TP.CM) med PGN 60160. En anslutning initieras mellan två noder genom att noden med data att skicka, skickar en Request To Send(RTS) innehållande datastorlek och hur många paket den är uppdelad i. Datan som överförs beskrivs med en PGN som inkluderas i de tre sista bytsen i allaTP.CM-meddelande. Den andra noden svarar medClear To Send (CTS) innehållande sekvensnummer på nästa paket och storlek på sändningsfönstret. Därefter skickas meddelande med dataTP.DToch besvaras med ytterligare CTS om sändningsfönstret fylls innan all data har blivit överförd. Anslutningen avslutas med att den mottagande noden skickar en End of message ACK med kvittens på mottagna bytes och paket. Ett exempel på en överföring kan ses i figur 2.6 där 12 bytes överförs och är uppdelad i 2 paket. Sista paket innehåller 5 bytes data men fylls på med 2 bytes med FF16
i vardera och behåller på så sätt en datalängd i CAN-meddelandet på 8 bytes.
Sekvensnummer i dataöverföringar startar på 1 och eftersom det representeras med 1 byte medför det att det endast går att skicka 255 paket i en överföring.
Bakgrund och teori | 13
Detta innebär en maximal meddelandestorlek för J1939-dataöverföringar på 1785 bytes med 7 bytes per paket.
Figur 2.6 – Exempelöverföring av PGN 65242. Datalasten har en storlek på 12 bytes och är uppdelad i 2 paket, sändningsfönster 2.
2.3 Bootloader
Mikrokontrollern på Arduino Nano är en Atmel ATmega328p-processor med klockfrekvensen 16MHz, 32kB flashminne, 2kB RAM-minne och 1kB EEPROM-minne. Flashminnet är uppdelat i två sektioner, Read-While-Write (RWW) och No-Read-While-Write (NRWW). Under skrivning till RWW- delen av flashminnet är det enbart möjligt att läsa från NRWW-sektionen.
Under en mjukvaruuppdatering är det viktigt att ingen kod läses från RWW- delen, eftersom det kan leda till oförutsett beteende [7].
En bootloader är mjukvara som generellt fyller två syften när den används i en mikrokontroller, dels att initiera minne och annan hårdvara för att operativsystemet eller den programvara som ska köras ska fungera, dels att erbjuda möjlighet för mjukvaruuppdateringar utan användning av en extern
14 | Bakgrund och teori
programmerare. När strömmen till mikrokontrollern slås på exekverar
processorn instruktionen på den plats i flashminnet som är definerad av CPU- tillverkaren.
Bootkod och applikationskod skiljs åt i flashminnet genom att minnet fördelas i en bootloader- respektive applikationssektor. Storleken på sektorerna kan ändras på ATmega328p genom modifieringar av fuses, vilka är inställningar som kan anpassas med en extern programmerare. I figur 2.7 visas ATme- ga328p:s ursprungliga uppdelning av flashminnet i applikations- respektive bootloadersektor.
Figur 2.7 – Flashminne ATmega328p
Varje sektor har egna så kallade lock bits som används till att sätta olika nivåer av säkerhet enligt nedan:
• Förhindra modifieringar av hela flashminnet;
• Förhindra modifieringar av sektorn där bootloadern finns placerad;
• Förhindra modifieringar av sektorn där applikationen finns placerad;
• Tillåta modifieringar av hela flashminnet.
2.3.1 Minnesarkitektur
Ett ATmega328p-flashminne är uppdelat i 256 st pages där varje page består av 128 bytes. Adressering inom en page sker med words där varje word
Bakgrund och teori | 15
består av 2 bytes. För att genomföra en skrivning till en page behöver först all data raderas vilket sker genom att sätta alla bitar till logiska ettor eftersom det endast är möjligt att ändra en individuell bit till logisk 0. Det leder till att en flashsektor har samma storlek som en page, dvs 128 bytes. Varje page adresseras individuellt genom byte-adressen för det första elementet.
Programräknaren är 14 bits stor och bit [13:6] används för att adressera en page, medan bit [5:0] adresserar words.
ATmega328p levererades med en bootloader vid namn AtmegaBoot som är 2kB stor och stödjer skrivning till flashminnet via UART. Mjukvaru- uppdateringar sänds över från datorn via USB-kabel till USB-kontrollern på mikrokontrollern där det konverteras till UART-kommunikation som boot- loadern avläser. STK500 är det protokollet som definierar kommandon för att styra uppdateringsprocessen. Framförallt är de två följande kommandona av intresse:
STK_LOAD_ADDRESS: 2 bytes som specificeras vilken adress kommande databytes ska skrivas till. Adressen är angiven i words, bootloadern översätter det till byte adress genom att multiplicera med två.
STK_PROG_PAGE: En byte som talar om skrivningen ska ske till flashminne eller EEPROM, en byte som talar om hur många bytes som ska skrivas till den aktuella pagen. Därefter börjar de bytes som ska skrivas till pagen att läsas in. När all data överförts raderas datan på pagen. Därefter fylls den temporära skrivbufferten som är en 16-bitars vektor med 64 platser. Se exempel i kodavsnitt2.2 där SPM_PAGESIZE är pagestorleken i antal bytes och variabeln buf pekar mot uppdateringsdatan som lästs in från UART.
Funktionen boot_page_fill placerar varje 16-bitars tal i den temporära skrivbufferten.
for (i=0; i<SPM_PAGESIZE; i+=2) {
// Set up word from temp buffer.
uint16_t w = *buf++;
w += (*buf++) << 8;
boot_page_fill (page + i, w); //fill (page + i ) address with word
}
Kodavsnitt 2.2 – Fylla temporära skrivbufferten med words[8]
16 | Bakgrund och teori
Metoder | 17
Kapitel 3 Metoder
Det här kapitlet är uppdelat i fyra delar. Den första delen beskriver en litteraturstudie för arbetet. Den andra delen beskriver valet av bootloader och metoder för att initiera CAN-uppdatering. Tredje delen beskriver metodval relaterade till kommunikationen över CAN-nätverk. Kapitlet avslutas med testfall av tidsåtgången för en uppdatering.
3.1 Litteraturstudie
En av arbetsmetoderna var att göra en litteraturstudie, inledningvis som förarbete men också fortlöpande genom hela arbetets gång. Områden som studerades var:
• Tidigare arbeteten som rörde bootloadermanipulering, flashningsmetoder för mikrokontroller och uppdatering av mjukvara via CAN,
• Datablad för hårdvarukomponenterna MCP2515, TJA1050 och ATmega328p,
• Programmeringsbibliotek för att använda MCP2515-modulen,
• Olika bootloaders till mikrokontroller,
• Dokumententation av SAE J1939-standarden.
Resultatet av litteraturstudien redovisas i arbetets andra kapitel.
18 | Metoder
3.2 Bootloader
3.2.1 Val av bootloader
Alternativen som utvärderades för valet av bootloader var att skriva en helt ny bootloader från grunden med stöd för både uppdatering via USB och CAN eller implementera stöd för CAN-kommunikation i en redan existerande bootloader. Utveckling av en egen bootloader valdes bort på grund av, att det ansågs, att arbetets omfattning skulle öka till en sådan grad att tiden inte skulle räcka till. En ytterligare motivering var att det fanns flera alternativ till bootloaders förutom Arduino Nanos standard bootloader som istället kan modifieras.
Valet av bootloader blev Optiboot vilket baserades främst på den låga grundstor- leken på 512 bytes vilket är av stor betydelse då CAN-kommunikationen behöver rymmas i NRWW-sektionen av minnet. Optiboot är den officiella bootloadern för exempelvis Arduino Uno och har även stöd för återställning av watchdog vilket inte fungerade i ATmegaBoot som Nano levererades med [9].
Installationen av Optiboot på mikrokontrollern genomfördes med AVRDUDE vilket är ett programverktyg som används för att hantera AVR-processorer.
Eftersom bootloadern lagras i NRWW-sektorn kan den inte uppdatera sig själv och bootloaderkoden behövde därför laddas upp med en extern program- merare. Två olika programmerare användes: En Arduino Uno med Nick Gammons externa programmerar sketch [10] som kopplades till Nanon, se tabell3.1och en AVRISP STK500 USB som kopplades in på mikrokontrollens In Circuit Serial Programming(ICSP) anslutning.
Arduino Uno Arduino Nano
MOSI MOSI
MISO MISO
SCK SCK
SS RESET
5V 5V
GND GND
Tabell 3.1 – Koppling Arduino Uno som extern programmerare för Nano
Metoder | 19
3.2.2 Inträdesvilkor till bootloadern
För att erbjuda snabbare uppstartstider undersöks orsaken till återställningen tidigt i Optiboot genom att kontrollera Mikrokontrollerns Status Register (MCUSR). De olika återställningsorsakerna är watchdog, brown-out, extern och power-on. För att köra bootloadern ska återställningsregistret vara tomt alternativt att extern återställning är den enda orsaken till återställningen. Se kodavsnitt3.1för Optiboot ursprungliga kontroll för huruvida applikation eller bootloader ska startas.
ch = MCUSR;
if ( ch != 0 ) {
// Skip all logic and run bootloader if MCUSR is cleared (application request)
if ( ch != 0 ) {
if ( ( ch & ( _BV(WDRF ) | _BV ( EXTRF ) ) ) != _BV ( EXTRF ) )
{
watchdogConfig(WATCHDOG_OFF);
__asm__ __volatile__ ("jmp 0\n");
} } }
Kodavsnitt 3.1 – Optiboot startvillkor [11]
I alla andra fall sker ett hopp till applikationens startadress. Eftersom det inte går att orsaka en extern återställning med mjukvara, finns det två möjligheter att starta bootloadern från en körande applikation.
(1) Modifiera villkoret för att starta bootloadern genom att kontrollera ytter- ligare en flagga som sparas i EEPROM. När applikationen vill starta boot- loadern skriver den ett värde till en definierad adress i EEPROM, konfigurerar watchdog timern med ett kort intervall som tillåts löpa ut för att orsaka en återställning av mikrokontrollen.
(2) Tömma återställningsregistret och genomföra ett funktionshopp till boot- loaderns startadress. Inga modifieringar behöver då göras i startvillkoren för Optiboot.
Metod (1) valdes dels eftersom det ger bootloadern en ren start utan eventuella
20 | Metoder
initieringar och minnesallokering som skett i applikationen. Ytterligare en för- del med att sätta en flagga i ett icke-flyktigt minne innan mjukvaruuppdatering påbörjas är att en misslyckad uppdatering kan återupptas ifall avbrott sker innan den slutförts. Genom att modifiera startvillkoren ges användaren möj- lighet att initiera uppdateringen genom att göra mikrokontrollern strömlös och påbörja uppdatering när den startas. Den byte i EEPROM som används till villkoret för att uppdatera via CAN har fått namnetUppdateringsstatusflaggan (USF) i det här arbetet.
3.3 Kommunikation med CAN
De flesta applikationer som körs på en mikrokontroller är större än J1939-21 maximala meddelandestorlek på 1785 bytes. På grund av detta undersöktes ISO Standard 15765-2 transport protocol (ISO-TP) då den också använder sig av CAN-protokollet och definierar de övre lagren i ISO-modellen. Enligt standarden är det möjligt att skicka meddelanden med en teoretisk storlek på 4Gb[12]. Den har också möjlighet att fungera i samma CAN-nätverk som J1939 då den använder sig av en PGN, vilket medför en lättare implementation av dataöverföring än J1939:s transportprotokoll som använder tre PGN:s.
Beslutet blev att använda J1939-21 transportprotokoll eftersom oavsett storlek på uppdateringen kan mikrokontrollern endast skriva en page i taget, 128 bytes för ATmega328p. Dessutom antogs det att kodens komplexitet skulle öka om den innehöll stöd för ytterligare ett protokoll även om ISO-TP anses vara enklare i sin implementation.
3.3.1 Filter och masker
Filter och masker skulle appliceras på meddelanden till uppdateringsverktyget respektive mikrokontrollern. En lista skapades med kriterier som filter och masker skulle förhålla sig till. Kriterierna var följande:
• Standard ID - J1939 använder endast utökat ID,
• Extended data page bit - J1939 använder inte biten och ska alltid vara 0.
• RTR-ramar - J1939 använder inte RTR-biten och ska alltid vara 0.
• Ytterligare filtrering av J1939-ramar för att tillåta endast PGN:s av intresse:
Metoder | 21
– Transport protocol connection management PGN 60416 (00EC0016), – Transport protocol data transfer PGN 60160 (00EB0016),
– ACK, PGN: 59392 (00E80016),
– Proprietary A PGN 61184 (00EF0016).
3.3.2 Virtualisera CAN
I syfte att underlätta felsökningen under programutvecklingen beslutades det att utföra så mycket av programmeringen som möjligt i en virtuell miljö. Ett CAN-nätverk skapades mellan persondatorer med hjälp av socketCAN och socketCAND. SocketCAND är en utökning av socketCAN med möjlighet att skicka CAN-meddelande med TCP/IP-protokollet. På så sätt gick det att simu- lera kommunikationen mellan uppdateringsverktyget och mikrokontrollerns mjukvara. Ett virtuellt CAN-gränssnitt kan skapas på en dator med Linux operativsystem genom kommandona:
$ sudo modprobe vcan
$ sudo ip link add dev vcan0 type vcan
$ sudo ip link set vcan0 up
En CAN-server som accepterar anslutningar över TCP/IP med hjälp av socket- CAND kan skapas genom kommandona (enp0s31f6 är nätverksgränssnittet för datorn):
$ socketcand -l enp0s31f6 -i vcan0
3.4 Hårdvara och tester
Alla tester och utveckling har skett med noder innehållande hårdvaran som kan ses i delen CAN-nätverket figur2.4. Längden på kablarna CAN high och CAN low mellan noderna är 20 cm långa och stödjer CAN2.0B:s maximala hastighet på 1 Mbps.
Tidsåtgång skrivning av page En skrivning till en page innefattar moment- en radering, skrivning och modifieringar av lock bits och tar mellan 3,7 och 4,5 ms [4].
CAN-hastighet Olika överföringshastigheter testades för att undersöka upp- dateringstiden och se i vilken mån det uppstod felaktiga överföringar. Över- föringshastigheterna som testades var 125, 250, 500 och 1000 kbps.
22 | Metoder
Uppdateringsstorlekar Två olika uppdateringsstorlekar testades dels för att se hur det påverkade tiden det tog för en uppdatering och dels för att undersöka beteendet på mikrokontrollern vid flashminnesskrivningar. Upp- dateringsstorlekar som testades var 246 bytes, en enkel applikation som blinkar en led varje sekund, och en skrivning av hela applikationssektorn på 28 kB.
Resultat | 23
Kapitel 4 Resultat
Kapitlet börjar med en beskrivning av de J1939PGN:s som användes i arbetet och kriterier för filtrering av CAN-ramar. Därefter beskrivs de modifieringar av bootloadersektorn som genomförts, följt av programutvecklingen i tre delar samt verifieringen utav uppdateringen. Kapitlet avslutas med en beskrivning av hur uppdateringen genomförs och resultaten från de tester som utfördes.
4.1 SAE J1939 PGN:s
Uppdateringsverkyget och bootloadern har stöd för J1939 genom att de accept- erar meddelanden med vissa PGN:s.Proprietary A(PA) är en av de PGN:s som används och fyller två funktioner: att styra övergångarna mellan uppdaterings- processens olika faser och att koppla TP.CM-meddelanden till uppdaterings- processen. Definitionen avPAför det här arbetet kan ses i bilagaA.1.
PA-meddelandet har också kravet att det ska besvaras med J1939-21 kvittens- meddelande, Acknowledge (ACK). Gruppfunktionen, SPN 2542 för ACK, antar värdet av PA:s kontrollbyte. En lista över de PGN:s som förekommer i det här arbetet kan ses i tabell 4.1 och mer detaljer om ACK-meddelandet kan ses i bilagaA.2.
4.1.1 Filter och masker
Uppdateringsverktyget och noderna har två filter och masker vardera. Alla standard ID filtreras bort i både uppdateringsverktyget och noderna. Utökade ID filtreras på olika sätt eftersom olika typer av meddelanden tas emot av
24 | Resultat
Namn PGN Mottagare
PA 61184 Nod
ACK 59392 Uppdateringsverktyg TP.CM 60416 Nod, uppdateringsverktyg TP.DT 60160 Nod
Tabell 4.1 – J1939-meddelande och deras PGN för arbetet.
uppdateringsverktyget och noderna. Samtliga masker och filter kan ses i tabell 4.2.
Användare ID typ Mask Filter
Nod, uppdateringsverktyg Standard 7FF 000
Nod Utökad 1BF8FFFF 18E8(DA)(SA)
Uppdateringsverktyg Utökad 1BFB00FF 18E800(SA) Tabell 4.2 – Masker och filter för noder och uppdateringsverktyget.
4.2 Modifiering av bootloader
Storleken på Optiboot är i sitt grundutförande 512 bytes och startar från adress 7E0016i flashminnet. För att utnyttja hela NRWW-sektorn till förmån för boot- loadern är den förändrad på två sätt: (1) modifierad instruktion till länkaren som specifierar var koden ska placeras i minnet och (2) processorns fuses är omställda för att reset-vektorn ska peka mot startadressen för bootloadern.
(1) För en bootloaderstorlek på 4096 bytes blir startadressen 700016och är satt med följande länkardirektiv:
atmega328: LDSECTIONS = -Wl,--section-start=.text=0x7000 -Wl,--section-start=.version=0x7ffe
(2) High fuse används bland annat för att ställa in storleken på bootloadersek- torn och välja återställningsvektor. Den består av följande bitar:
• Bit 7:5 är lämnat i sitt standardutförande eftersom det påverkar program- meringen av processorn,
• Bit 4 är lämnat i sitt standardutförande eftersom en konstant påslagen watchdog ställer krav på att applikationerna kontinuerligt behöver för- hindra att den återställer mikrokontrollern.
Resultat | 25
• Bit 3 är programmerad för att behålla minnet i EEPROM mellan mjukvaruuppdateringar för att uppfylla kravet om lagring av NOD-ID i EEPROM.
• Bit 2:1 är programmerade för att erhålla en bootloadersektor på 4096 bytes.
• Bit 0 är programmerad för att reset-vektorn ska peka på bootloaderns startadress.
Beskrivning av de olika high-fuse bitarna ses i tabell4.3och minnnesstruktu- ren efter förändrade länkardirektiv och fuse-inställningar kan ses i figur4.1.
High fuse bit Funktion Standardinställning
7 Extern återställning 1 (oprogrammerad)
6 debuganslutning aktiverad 1 (oprogrammerad) 5 Serial programmering aktiverad 0 (programmerad)
4 Watchdog alltid på 1 (oprogrammerad)
3 EEPROM sparas vid flashning 1 (oprogrammerad)
2 Storlek på bootsektorn 0 (programmerad)
1 Storlek på bootsektorn 0 (programmerad)
0 Val av resetvektor 1 (oprogrammerad)
Tabell 4.3 – High fuse parametrar
26 | Resultat
Figur 4.1 – Minnesstruktur efter ändrade länkardirektiv och fuse
4.3 Programutveckling för mikrokontroller
Den första delen av programutvecklingen för mikrokontroller beskriver appli- kationskod som kan initiera CAN-uppdateringen från en körande applikation på mikrokontrollern. Den andra delen handlar om hur bootloadern Optiboot är modifierad för att kunna ta emot uppdateringen och skriva den till flashminnet.
4.3.1 Koden i applikationsminnet
För att starta bootloadern från en körande applikation på mikrokontrollern är antagandet att applikationen uppfyller två kritierer: att kunna ta emot CAN-meddelanden och att förstå meddelanden av SAE J1939 standard. När applikationen tar emot en reset-request från uppdateringsverktyget skriver den följande information till EEPROM: CAN-uppdatering är aktiv och vilken CAN-hastighet som ska användas. Sedan startar en watchdog-timer som tillåts löpa ut för att en återställning ska genomföras. Den funktion som anropas när en reset-request tas emot av applikationen kan ses i kodavsnitt4.1.
Resultat | 27
void start_can_flash() {
eeprom_update_byte((uint8_t*)FLASH_STATUS_ADDR, FLASH_ACTIVE);
eeprom_update_byte((uint8_t*)CAN_BAUDRATE_ADDR, CAN125kbps);
send_can_message(ACK0);
wdt_enable(WDTO_15MS);
while(1) {}
}
Kodavsnitt 4.1 – Initiera uppdatering: SättUSFsom aktiv, sätt CAN-hastighet, skickaACKoch utför en reset.
4.3.2 Implementering av CAN i bootloader
Det ursprungliga villkoret för att starta bootloadern accepterar inte watchdog som återställningsorsak och är därför modifierat. IfallUSFi EEPROM indike- rar att en uppdatering via CAN pågår, alternativt att mikrokontrollern startar efter att ha varit strömlös, nollställsMCUSRvilket leder till att startvillkoret uppfylls. Om en mjukvaruuppdatering skulle avbrytas innan den slutförs eller att felaktig mjukvara körs på mikrokontrollern, ger det användaren ett nytt för- sök till mjukvaruuppdatering via CAN. Det modifierade startvillkoret kan ses i kodavsnitt4.2där FLASH_STATUS_ADDR definierar adressen i EEPROM där USF lagras, och PORF (Power-on-reset flag) visar om mikrokontrollern startar från strömlöst tillstånd.
För att behålla möjligheten till mjukvaruuppdatering via USB avgör USF i EEPROM och Power-on-reset flaggan i MCUSR om CAN ska användas som källa till uppdateringen. Kontrollen sker innan USB-porten börjar läsas av;
koden finns att se i kodavsnitt4.3och flödesdiagram i figur4.2.
28 | Resultat
ch = MCUSR;
const uint8_t flash_status =
eeprom_read_byte((uint8_t*)FLASH_STATUS_ADDR);
if( (flash_status == 1) | ( ch & ( _BV ( PORF ) ) ) ) {
ch = 0;
}
if ( ch != 0 ) {
// Skip all logic and run bootloader if MCUSR is cleared (application request)
if ( ch != 0 ) {
if ( ( ch & ( _BV(WDRF ) | _BV (EXTRF ) ) ) != _BV ( EXTRF ) )
{
watchdogConfig(WATCHDOG_OFF);
__asm__ __volatile__ ("jmp 0\n");
} } }
Kodavsnitt 4.2 – Optiboot modifierat startvillkor
if ( (flash_status == 1) | (MCUSR & ( _BV ( PORF ) ) ) ) { {
MCUSR = ~ ( _BV ( PORF ) );
can_main();
}
for ( ;; ) {
/* get character from UART */
ch = getch();
}
Kodavsnitt 4.3 – Val av uppdateringskälla
Resultat | 29
Figur 4.2 – Optiboot modifierade startvillkor
4.4 Uppdateringsverktyget
Uppdateringsverktyget accepterar argument för att ge användaren möjlighet att anpassa uppdateringen. Ett exempel på användning av uppdateringsverktyget kan ses i kodavsnitt4.4där 0x55 är NOD-ID för den nod som ska uppdateras och firmware.hex är IntelHex-filen som innehåller uppdateringen. En lista på fler argument för uppdateringsverktyget kan ses i appendixB.1.
./can-flash-tool.py -d 0x55 -f firmware.hex
Kodavsnitt 4.4 – Användning av uppdateringsverktyget
IntelHex-filer läses in med hjälp av biblioteket IntelHex skapat av Alexander Belchenko [13]. Ytterligare moduler som uppdateringsverktyget använder sig av är från Pythons standardbibliotek: zlib och argparse. Modulen Sta- temachine, skrivet av Fernando Macedo[14], står för strukturen under hela uppdateringsprocessen. Tillståndsdiagram kan ses i figur4.3.
30 | Resultat
Figur 4.3 – Tillståndsmaskinen i uppdateringsverktyget. IN är ett mottaget J1939-meddelande och OUT är ett skickat.
4.5 Verifiering av mjukvarudata
Cyclic Redundancy Check (CRC) är en av de vanligaste metoderna för att beräkna kontrollsummor inom dataöverföring och datalagring. För att verifiera att det som skrivits till mikrokontrollerns flashminne stämmer överens med innehållet i Intel Hex-filen, beräknas 32-bitars CRC med generatorpolynomet EDB8832016, vilket är samma som används vid Ethernet, ZIP med mera.
CRC32 med generatorpolynomet EDB8832016anses vara tillräckligt noggrant då:
Resultat | 31
• Möjligheter att upptäcka fel [15]:
– Alla enskilda bitfel kan upptäckas, – Alla udda bitfel kan upptäckas,
– Alla skurfel på upp till 32-bitar kan upptäckas,
– Risken att ett skurfel på 33-bitar inte upptäcks är 5 på 10 miljarder.
– Risken att ett skurfel på 34-bitar eller mer inte upptäcks är 3 på 10 miljarder.
Beräkningen av CRC i uppdateringsverktyget görs med modulen zlib för python [16]. Startvärdet för beräkningen är 0 och det beräknade resultat avslutas med logisk AND med talet FFFFFFFF16 för att generera samma resultat i alla versioner av python.
Implementationen av CRC på mikrokontrollern behövde genomföras med en page i taget eftersom inte all uppdateringsdata ryms i RAM samtidigt. Det initiala startvärdet för beräkningen är 0 och resultatet för varje page används som startvärde för beräkning av efterkommande page.
4.6 Uppdateringsprocessen
Uppdatering av mikrokontrollerns applikation är uppdelad i fyra faser: initie- ring, överföring, verifiering och avslut.
4.6.1 Fas 1 – Initiering
Uppdateringen inleds med att uppdateringsverktyget skickar ettPA-meddelande som besvaras med en ACKav mikrokontrollern, antingen från applikationen som körs eller från bootloadern. Kommunikationen mellan de båda parterna kan ses i figur4.4.
32 | Resultat
Figur 4.4 – Initiering av uppdateringsprocessen.
4.6.2 Fas 2 – Överföring
Uppdateringsverktyget skickar uppdateringsdata en page i taget tillsammans med page-adressen, vilket innebär 128 + 2 bytes per J1939 TP.CM-session.
Alla pages utom eventuellt den sista är fulla vilket kräver 19 datapaket för att överföras ochCTS-meddelandet anger ett sändningsfönstret på 1. Figur4.5 visar kommunikationen mellan nod och uppdateringsverktyg vid överföringen av en data page. Överföringsfasen avslutas när uppdateringsverktyget tar emot EndOfMsgACK för sista pagen.
4.6.3 Fas 3 – Verifiering
När hela uppdateringen skrivits till mikrokontrollerns programminne skickar uppdateringsverktyget ettPA-meddelande som innehåller en kontrollsumma som beräknats med CRC32 på Intel Hex-filen. Mikrokontrollern beräknar CRC på sitt programminne och jämför de två kontrollsummorna. Ifall de stäm- mer överens skickar den ettACKtill uppdateringsverktyget som bekräftelse.
Resultat | 33
Figur 4.5 – Överföring av en page med data.
4.6.4 Fas 4 – Avslut
När uppdateringsverktyget har fått bekräftat att kontrollsummorna stämmer överens skickar den ettPA-meddelande. Mikrokontrollern tar emot meddelan- det, skickar enACK, sätterUSFtill inaktiv och låter watchdog-timern löpa ut.
Eftersom det inte har skett någon extern återställning ochUSFinte indikerar att en CAN-uppdatering ska genomföras, sätts programräknaren till adress 000016 där applikationen börjar.
34 | Resultat
4.7 Tester
För att mäta tidsåtgången vid mjukvaruuppdatering genomfördes tester med olika överföringshastigheter och uppdateringsstorlekar. Sändningsfönstret var ett datapaket per CTS och varje testfall genomfördes fem gånger för att få ett medelvärde. Vid testet var en nod och uppdateringsverktyget inkopplade i nätverket. Resultat kan ses i tabell4.4.
Uppdateringsstorlek 125 kbps 250 kbps 500 kbps 1000 kbps
246 bytes 8,11 s 2,77 s 2,54 s 2,99 s
27.996 bytes 19,96 s 16,66 s 12,93 s 11,1 s
Tabell 4.4 – Tidsåtgång vid olika uppdateringsstorlekar och överföringshas- tigheter
Analys och diskussion | 35
Kapitel 5
Analys och diskussion
Det här kapitlet börjar med att analysera testerna som genomförts och ger förslag på fler funktioner för uppdateringsverktyget och mikrokontrollern.
Därefter presenteras några alternativa lösningmetoder och förslag på förbätt- ringar som kan implementeras i både uppdateringsverktyget och noderna.
Kapitlet avslutas med diskussion om hållbar utveckling och etik i relation till slutprodukten.
5.1 Sändningsfönter
J1939 transportprotokoll kan skicka upp till 1785 bytes per RTS och till- hörande CTS. Den presenterade lösningen har ett sändningsfönster på ett datapaket per CTS för att eliminera risken för överfyllda buffertar och behovet av omsändningar. Nackdelen blir en overhead på 21 CAN-paket per page (1 RTS + 19 CTS + 1 EOMACK). Då skrivning sker en page i taget och RAM- minnet är begränsat är det inte lämpligt att skicka mer än en page i taget. En teoretisk beräkning där en CAN-ram antas vara 128 bits, överföringshastighet på 125 kbit/s och sändningsfönstret ökas till 19 paket per CTS skulle resultera i en tidsbesparing på:
Sändningsfönster på 1 paket per CTS, 19st datapaket: 1 RTS, 19 CTS, 19 datapaket och 1 EOMACK = 40 paket.
128 ∗ 40/125.000 = 0, 041sekunder. (5.1) Sändningsfönster på 19 paket per CTS, 19 datapaket: 1 RTS, 1 CTS, 19
36 | Analys och diskussion
datapaket och 1 EOMACK = 22 paket.
128 ∗ 22/125000 = 0, 0225sekunder (5.2) För en uppdatering av hela programminnet på 28kB och 224 pages blir det en tidsbesparing på
(0, 041 − 0, 0225) ∗ 224 = 4, 144sekunder (5.3) Vid användning på en mikrokontroller med större flashminne blir tidsbespa- ringen ännu större, därav uppmanar vi till framtida arbete för större CTS- fönster och en metod för omsändningar av eventuella paket som förloras.
5.2 Parameter Gruppnummer
Fler PGN:s i J1939-standarden finns tillgängliga att definiera för utvecklare och detta kan ge möjlighet att lägga till flera funktioner för uppdaterings- verktyget och bootloadern. Sådana funktioner kan t.ex. vara att läsa mikro- kontrollerns flash och EEPROM eller skicka kommandon genom ett terminal- läge för uppdateringsverktyget, likt programmeringsverktyget AVRDUDE som bland annat används av Arduino IDE. Detta beror också på hur J1939 PGN:s används i det befintliga nätet, då de kanske redan är definierade. Något att ha i åtanke dock är att det är begränsat med möjliga PGN:s, inte minst för att definiera själv (Proprietary), och är därför viktigt att använda dem sparsamt och genomtänkt. På grund av den anledningen användes endast en PGN, Proprietary A, både till att skicka som meddelande och beskriva innehållet i dataöverföring.
5.3 Optimering av mjukvarukod
Den slutgiltiga versionen av bootloadern har en storlek på 3396 bytes och ligger i en bootloadersektor på 4 kB vilket är det största möjliga alternativet för ATmega328p. Under projektets gång fanns det inte tid att optimera för att få den att rymmas i den näst största storleken på bootloadersektorn, vilket är 2 kB. Ifall användaren behöver mer än 28 kB för applikationen, men använder bara mjukvaruuppdatering via CAN, är ett förslag att ta bort stödet för UART-kommunikation. Uppdragsgivaren för det här projektet önskade fortsatt stöd för mjukvaruuppdatering via USB-kabel, men om noden sitter på ett svåråtkomligt ställe och uppdatering via USB sällan används kan det
Analys och diskussion | 37
vara ett alternativ att överväga.
Bootloadersektorn går att ställa in på 512, 1024, 2048 och 4096 bytes.
Eftersom att applikationskod inte kan ligga i bootloadernsektorn finns det ingen anledning att spara in på bootloaderkod om man inte går under 2 kB. Exempelvis en integritetskontroll vid uppstart av mikrokontrollern ifall säkerhet är av hög relevans. För att minska tiden för beräkningen av CRC kan en tabell med möjliga kontrolsummor sparas i flashminnet.
5.4 Uppdateringsmetoder
Driftsäkerhet kan vägas mot applikationsstorlek genom att, som Dr. P.T Karule och P. Selokar gjorde i sitt arbete [2], använda halva flashminnet till att lagra en temporär kopia av uppdateringen innan den skrivs till minnet. Detta är en säker metod eftersom det finns en backup i flashminnet tills dess att uppdateringen skett korrekt. I fallet för ATmega328p är sannolikheten hög för att dess 28 kb utgör ett för litet minne för många applikationer och därför valdes denna metod bort i detta arbete.
5.5 Återhämtning vid fel
Den utvecklade uppdateringsmetoden använder watchdog för att starta om mikrokontrollern om någonting går fel under uppdateringsprocessen. Det leder till att en misslyckad uppdatering behöver börja om från början vilket kom- mer leda till mycket omsändningar och längre tidsåtgång. Mikrokontrollern innehåller tre stycken timers som kan användas istället för watchdog och erbjuda möjlighet för en kontrollerad återhämtning efter att ett fel uppstått.
Vi föreslår implementation av en timer som orsakar interrupt när tiden har tagit slut, och då meddelar uppdateringsverktyget vilket steg i uppdateringen den är i. Uppdateringsverktyget behöver även modifieras för att stödja den här förbättringen.
5.6 Hållbar utveckling och etik
Målgruppen för examensarbetet är i första hand uppdragsgivaren vilket för- anledde krav på vilken hårdvara slutprodukten behövde vara kompatibel med. Som följd saknar slutprodukten stöd för mikrokontroller eller CAN- moduler av andra modeller. Dock krävs inga omfattande modifieringar för att
38 | Analys och diskussion
mjukvaran ska fungera med liknande komponenter vilket i kombination med Arduino stora marknadsandel bland lekmän skapar nytta för många.
Med tanke på att arbetet enbart skapat mjukvara som används istället för redan existerande mjukvara, påverkas inte miljön någonting av implementationen av slutprodukten. Vi har inte fokuserat på att minimera strömförbrukningen eftersom en mjukvaruuppdatering kräver att mikrokontrollern är aktiv hela tiden. Den del av arbetet som kan optimeras gällande strömförbrukning är i uppstartsfasen när mikrokontrollern varit strömlös. Vår implementation avvaktar i två sekunder innan applikationen startar, vilket orsakar onödig strömförbrukning. En effektivare lösning hade varit en kortare uppstartstid, där uppkopplingsfasen mellan mikrokontroller och uppdateringsverktyg är bättre synkroniserad.
Ur ett etisk perspektiv ökar risken för olovlig manipulation av en mikro- kontrollers mjukvara eftersom det inte krävs direkt fysisk tillgång via CAN.
För att manipulera mjukvaran krävs det kännedom om vilka NOD-ID som används, vilket försvårar för obehöriga. Möjligheten har även lämnats öppen för implementation av lösenord iPA, se bilagaA.1.
Slutsatser | 39
Kapitel 6 Slutsatser
Examensarbetet resulterade i en fungerade metod för att genomföra mjukvaru- uppdateringar av en specifik nod i ett CAN-nätverk. Det har visats att J1939 som kommunikationsprotokoll är lämpligt för mjukvaruuppdateringsproces- sens olika faser vilket möjliggör migrering till ett nätverk där övrig kom- munikation använder J1939. Slutprodukten bestod dels av en bootloader som utöver sitt ursprungliga stöd för uppdatering via USB även har stöd för att ta emot uppdateringsdata via CAN och skriva den till minnet. Ett uppdateringsverktyg som utvecklats i Python och använder Intel HEX-filer som källa till uppdateringen och använder J1939 adressering för att välja vilken nod i nätverket som ska uppdateras. För att garantera dataintegriteten av mjukvaruuppdateringen beräknades en kontrollsumma med CRC32 för det som skrivits till programminnet.
Mikrokontrollern ATmega328p är väletablerad mycket tack vare Arduino och används av lekmän i en mängd olika projekt. Tidigare anpassningar av bootloadern för ATmega328p har gjorts, men inte specifikt för CAN- protokollet då det främst används inom fordonsindustrin och dessa lösningar generellt inte delas med allmänheten. Resultatet av det här arbetet kan därför komma till användning för personer som, precis som uppdragsgivaren, har ett fordon där ett eget anpassat sensorsystem ska implementeras.
Förbättringar för slutprodukten kan innefatta optimering av programmerings- kod för att minska bootloaderstorleken, minska uppdateringstiden genom att öka hur mycket uppdateringsdata som kan sändas per bekräftelse och nya funktioner för att till exempel kontrollera mikrokontrollerns version på mjukvaran.
40 | Slutsatser
REFERENSER | 41
Referenser
[1] Bootloader Design for Microcontrollers in Embedded Systems. Jacob Beningo; 2015 [updated 2015 Jun 26; cited 2020 Apr 12]. Availab- le from:https://github.com/Optiboot/optiboot/blob/
master/optiboot/bootloaders/optiboot/optiboot.c.
[2] Selokar PR, Karule DPT, editors. Firmware Upgradation of ARM7 through Communication Link. Department of Electronics and Commu- nication, Shri Ramdeobaba College of Engineering and Management, Department of Electronics Engineering, Yashwantrao Chavan College of Engineering; 2016.
[3] TJA1050 High speed CAN transceiver. Revision 4. Philips Semi- conductors; 2003.
[4] Stand-Alone CAN Controller with SPI Interface. Revision J. Microchip Technology Inc; 2019.
[5] SocketCAN - Controller Area Network [homepage on the Internet]. San Francisco, CA: Linux Kernel Organization, Inc.; 1993 - [updated 2020 Jan 19; cited 2020 Jan 10]. Available from:https://www.kernel.
org/doc/html/latest/networking/can.html.
[6] Surface vehicle recommended practice, J1939-21. DEC2010. SAE Inter- national; 1994.
[7] Atmel 8 bit Microcontroller with 4/8/16/32 kB In-System Programmable Flash. Revision. 8025I. ATmel; 2009.
[8] Bootloader Support Utilities; 2010 [updated 2010 Jan 6; cited 2020 Apr 25]. Available from: https://www.eit.lth.se/fileadmin/
eit/courses/edi021/avr-libc-user-manual/group_
_avr__boot.html.
42 | REFERENSER
[9] Optiboot. Bill Westfield; 2020 [updated 2020 Mar 15; cited 2020 May 11]. Available from: https://github.com/Optiboot/
optiboot.
[10] Atmega bootloader programmer. Nick Gammon; 2014 [updated 2014 Nov 26; cited 2020 May 17]. Available from:http://www.gammon.
com.au/bootloader.
[11] Optiboot.c. Bill Westfield; 2020 [updated 2020 Mar 15; cited 2020 May 11]. Available from: https://github.com/Optiboot/
optiboot/blob/master/optiboot/bootloaders/
optiboot/optiboot.c.
[12] Vägfordon– Diagnostikkommunikation över CAN (DoCAN)– Del 2:
Transportprotokoll och tjänster för nätverksskikt. SS-ISO 15765-2:2016.
Swedish Standards Institute; 2016.
[13] Python library for Intel HEX files manipulations. Beaverton, OR 97008, USA: Python Packaging Authority; 2013 - [updated 2018 Jan 30; cited 2020 Maj 10]. Available from: https://pypi.org/project/
IntelHex/.
[14] Python Finite State Machines made easy.. Beaverton, OR 97008, USA:
Python Packaging Authority; 2017 - [updated 2020 Jan 30; cited 2020 Maj 10]. Available from: https://pypi.org/project/
python-statemachine/.
[15] Forouzan. In: Data Communications and Networking. 5th ed. McGraw- Hill education; 2012. p. 270 – 273.
[16] zlib — Compression compatible with gzip; [updated 2020 Jun 5; cited 2020 Jun 6]. Available from: https://docs.python.org/3/
library/zlib.html.
Appendix A: SAE J1939 | 43
Bilaga A SAE J1939
A.1 Proprietary A
Används till att byta fas i uppdateringsprocessing av en applikation. Innehåller även information nödvändiga för att genomföra en uppdatering. Kräver en ACK eller NACK som svar.
Data length: 8 bytes
Extended data page: 0
Data page: 0
PDU format: 239
PDU specific: Destinationsadress Default priority: 6
Parameter Group Number: 61184 (00EF0016)
Data fält för parametrar som används i detta meddelande:
Kontroll byte: 0 till 3 Se definition längre ner.
4 till 255 Används inte.
Applikationens ID: 0 till 255 Valbart för användaren att definiera.
Appikationens version: 0 till 65535 Valbart för användaren att definiera.
44 | Appendix A: SAE J1939
Initieringsfas: Kontroll byte = 0
Byte: 1 Kontroll byte = 0, Initieringsfasen av uppdateringen.
2-8 Lösenord för att utföra reset annars fylld med FF16. Överföringsfas: Kontroll byte = 1
Byte: 1 Kontroll byte = 1, Överföringsfasen av uppdateringen.
2-3 Storlek på uppdateringen i antal bytes.
4 Antal pages som uppdateringen är uppdelad i.
5-8 Reserverade.
Verifieringsfas: Kontroll byte = 2
Byte: 1 Kontroll byte = 2, Verifieringsfasen av uppdateringen.
2-5 Beräknad CRC32 av uppdateringens data.
6-8 Reserverade.
Avslutningsfas: Kontroll byte = 3
Byte: 1 Kontroll byte = 3, Avslutningsfas av uppdateringen.
2-8 Reserverade.
A.2 Acknowledge
Acknowledge som definierad av SAE J1939-21
Data page 0
PDU format 232
PDU specific 255 (Global adress)
Priority 6
Parameter Group Number 59392 (00E80016)
Data byte Funktion
1 Kontroll byte
2 Gruppfunktion
3-4 SAE reserverad
5 Adresskvittering
6-8 PGN som kvitteras
Appendix A: SAE J1939 | 45
Gruppfunktionen, SPN 2542 (byte 2), definierad i detta arbete för Proprietary A i Acknowledge meddelandet.
Initieringsfas: Gruppfunktion byte = 0 Överföringsfas: Gruppfunktion byte = 1 Verfieringsfas: Gruppfunktion byte = 2 Avslutningsfas: Gruppfunktion byte = 3
A.3 Antal möjliga PGN:s
Enligt sida 14 i J1939-21 DEC2010[6] kan totala antaletPGNräknas ut genom följande ekvation:
(240 + (16 · 256)) · 2 = 8672 (A.1) Där 240 är antalet värden PDU format fältet kan anta per data page vid PDU1 format. 16 är antalet värden PDU format och 256 är antalet värden förGEför PDU specific fältet vid PDU2 format. 2 är antalet data pages (0 eller 1 för data page bit).
46 | Appendix B: Uppdateringsverktyget
Bilaga B
Uppdateringsverktyget
B.1 Argument vid körning
Argument för uppdateringsverktyget. Användning:
./can-flash-tool.py [-h] [-i I] -d D [-s S] -f F
Argument Beskrivning Standard Obligatoriskt
-i <I> CAN gränssnitt can0 Nej
-d <D> Destinationsadress för noden - Ja -s <S> Uppdateringsverktygets adress 7F16 Nej -f <F> Intel Hex-filen för uppdateringen - Ja
TRITA TRITA-CBH-GRU-2020:071
www.kth.se
