Uppgifter på fabriksgolvet
Viktigt!
Det här är dokumentationen om Azure Sphere (Legacy). Azure Sphere (Legacy) upphör den 27 september 2027 och användarna måste migrera till Azure Sphere (integrerad) vid den här tiden. Använd versionsväljaren ovanför TOC för att visa dokumentationen om Azure Sphere (integrerad).
Tillverkning av anslutna enheter som innehåller Azure Sphere-maskinvara omfattar följande uppgifter på fabriksgolvet för att förbereda enheter för leverans:
- Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet
- Hämta enhetsinformation och registrera dem för senare användning
- Uppdatera Azure Sphere-operativsystemet om det behövs
- Uppdatera det betrodda nyckelarkivet om det behövs
- Läser in programvara på enheten
- Köra funktionella tester för att verifiera produktens korrekta åtgärd
- Utföra radiofrekvenstestning och kalibrering
- Verifiera Wi-Fi-kommunikation
- Konfigurera enheten för Ethernet
- Slutför Azure Sphere-enheten för leverans
Du måste ansluta chipet till datorn först, hämta enhetsinformationen tvåa och slutföra enheten senast, men du kan utföra de andra uppgifterna i valfri ordning som passar din tillverkningsmiljö.
Viktigt!
Du bör förbereda dig för att se till att dina uppgifter på fabriksgolvet kan slutföras utan fördröjningar. Förberedelse omfattar installation av fabriksgolvet pc och annan nödvändig utrustning och installera nödvändiga PC-programverktyg. Alla uppgifter som du bör utföra för att förbereda för en smidig tillverkningsprocess beskrivs i Förberedelse av tillverkningsprocessen.
Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet
Under tillverkningen måste du ansluta varje Azure Sphere-chip till en dator på fabriksgolvet. Om du vill ansluta flera Azure Sphere-enheter samtidigt till en enda dator kan du läsa Utrustning för uppgifter på fabriksgolvet i tillverkningsförberedelseuppgifterna.
De flesta uppgifter på fabriksgolvet omfattar kommandot azsphere-enhet. När du har flera enheter anslutna till datorn måste du ange på vilken enhet azsphere-enhetskommandot ska tillämpas genom att inkludera parametern --device inställd på antingen enhetens IP-adress eller enhetens anslutningssökväg. Kommandot misslyckas om parametern --device utelämnas och flera enheter är anslutna. Information om hur du hämtar IP-adressen eller anslutningssökvägen finns i Hämta enhetsinformation.
Viktigt!
Azure Sphere 23.05 SDK-versionen och senare versioner stöder kommunikation med flera anslutna enheter i Windows och Linux.
Hämta enhetsinformation
Du måste registrera enhets-ID:t för varje Azure Sphere-chip som ditt företag införlivar i tillverkade produkter. Du behöver enhets-ID:t för molnkonfigurationsuppgifter.
Om du har flera enheter anslutna till datorn på fabriksgolvet måste du också registrera IP-adressen eller anslutningssökvägen för anslutna enheter för senare användning i aktiviteter på fabriksgolvet. Som beskrivs i Anslut varje Azure Sphere-chip krävs IP-adress eller anslutningssökväg för att ange målenheten när det finns flera anslutna enheter.
Om du vill hämta enhets-ID, IP-adress och anslutningssökväg för de anslutna enheterna använder du kommandot azsphere device list-attached. Följande beskrivningar innehåller viktig information om enhets-ID, IP-adress och anslutningssökväg.
Enhets-ID – Kiseltillverkaren skapar enhets-ID:t, lagrar det på chipet och registrerar det med Microsoft. Den här enhetsregistreringen säkerställer att Microsoft är medveten om alla Azure Sphere-chips och att endast legitima chips kan användas på anslutna enheter.
IP-adress – IP-adressen tilldelas när ett FTDI-baserat enhetsgränssnitt är kopplat till datorn. det anger inte att det finns en responsiv enhet. IP-adressen bevaras medan det FTDI-baserade enhetsgränssnittet är kopplat till datorn, även om en annan Azure Sphere-enhet är ansluten till gränssnittet. Efter en omstart av datorn kan dock IP-adressen ändras. Det första FTDI-baserade enhetsgränssnittet som ska kopplas tilldelas adressen 192.168.35.2. Varje enhet tilldelas en IP-adress , även om den inte svarar, så du kan använda IP-adressen för att identifiera en enhet som kräver återställning.
Anslutningssökväg – Anslutningssökvägen är ett FTDI-plats-ID som identifierar USB-anslutningen. Plats-ID:t bevaras medan det FTDI-baserade enhetsgränssnittet är anslutet till samma USB-port på samma USB-hubb och i sin tur till samma port på datorn. Därför behålls den över omstart. Ändringar i ledningar mellan datorn och enheten kan dock leda till ändringar i anslutningssökvägen. Precis som IP-adressen ändras den inte även om en annan Azure Sphere-enhet är ansluten till FTDI-gränssnittet.
Uppdatera Azure Sphere OS
Varje Azure Sphere-chip läses in med Azure Sphere OS när det levereras från kiseltillverkaren. Beroende på vilken version av Azure Sphere OS på chips som är tillgängliga från din leverantör, och beroende på versionskrav för operativsystemet i ditt program, kan du behöva uppdatera Azure Sphere OS under tillverkningen av den anslutna enheten. Du kan uppdatera operativsystemet genom att installera specifika återställningsavbildningar som redan ska finnas på datorn. Se Förbereda för en uppdatering av operativsystemet i tillverkningsförberedelseuppgifterna. Tillverkningsexemplen innehåller ett exempelskript som utför parallell återställning med flera enheter.
Du kan uppdatera operativsystemet på Azure Sphere-enheten genom att utfärda kommandot azsphere device recover . Använd parametern --images för att installera specifika återställningsbilder:
azsphere device recover --images <path-to-images> [--device <IP-address or connection-path>]
Kommentar
Om flera enheter är anslutna till datorn inkluderar du parametern --device för att identifiera målenheten med IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet.
Uppdatera det betrodda nyckelarkivet
Som en förutsättning för att läsa in programvara på enheten kan du behöva uppdatera det betrodda nyckelarkivet på enheten. Detta krävs endast om operativsystemet på enheten är äldre än din programvara och endast om signeringsnyckeln för Azure Sphere-avbildningen som används av AS3 uppdaterades mellan operativsystemet som publiceras och din programvara är produktionssignerad. Om du vill undvika det här steget och minska tillverkningstiden bör du överväga att uppdatera den operativsystemversion som du använder under tillverkningen.
Du kan enkelt avgöra om det krävs en uppdatering av det betrodda nyckelarkivet genom att försöka läsa in programvaran enligt anvisningarna i nästa avsnitt. Om inläsningen lyckas behöver du inte uppdatera det betrodda nyckelarkivet. Om inläsningen misslyckas med meddelandet som börjar med Internal device error: Image not trusted by device är ett inaktuellt betrott nyckelarkiv orsaken.
Om du vill uppdatera det betrodda nyckelarkivet måste du ha hämtat den uppdaterade betrodda nyckellagringsfilen. Som en del av dina tillverkningsskript använder du sedan kommandot azsphere device sideload deploy för att läsa in det uppdaterade betrodda nyckelarkivet innan du läser in programprogramvaran och ersätter <path-to-trusted-keystore.bin> med sökvägen till den betrodda nyckellagringsfilen:
azsphere device sideload deploy --image-package <path-to-trusted-keystore.bin> [--device <IP-address or connection-path>]
Läs in enhetsprogramvara
All programvara som du läser in – oavsett om det är en avbildning av brädkonfigurationen, ett testprogram eller ett produktionsprogram – måste vara produktionssignerad. Om du läser in ett tillfälligt program för testning måste du ta bort det när testningen är klar.
Alla produktionssignerade avbildningar som du behöver under processen på fabriksgolvet bör sparas på fabriksgolvet innan processen påbörjas, enligt beskrivningen i Hämta produktionssignerade avbildningar i tillverkningsförberedelseuppgifterna.
Under tillverkningen får Azure Sphere-enheter inte kräva några särskilda enhetsfunktioner, till exempel apputvecklingsfunktionen, som möjliggör felsökning. Att skaffa funktioner för enskilda enheter minskar enhetssäkerheten och kräver internetanslutning, vilket vanligtvis är oönskat på fabriksgolvet.
Om du vill läsa in programvara på en enhet i fabriken eller ta bort tillfällig programvara från en enhet när testningen är klar använder du kommandot azsphere device sideload enligt följande:
Använd azsphere device sideload deploy för att läsa in en avbildning och ersätt
<file-path>med namnet och sökvägen till din produktionssignerade avbildningsfil:azsphere device sideload deploy --image-package <file-path> [--device <IP-address or connection-path>]
Använd azsphere device sideload delete för att ta bort en tillfällig avbildning och ersätt
<component-id>med komponent-ID:t för avbildningen som ska tas bort:azsphere device sideload delete --component-id <component-id> [--device <IP-address or connection-path>]
Kommentar
Om flera enheter är anslutna till datorn inkluderar du parametern --device för att identifiera målenheten med IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet.
Köra funktionella tester
Funktionella tester krävs för att kontrollera att produkten fungerar korrekt. Kör de program som du har utvecklat för funktionell testning som en del av tillverkningsförberedelseuppgifterna. Se Utveckla program för funktionell testning.
Om dina funktionella tester kräver kommunikation med det chip som testas ansluter du MT3620-kringutrustningen (ISU0, ISU1, ISU2 eller ISU3) till antingen din dator på fabriksgolvet eller extern testutrustning via lämpliga kretsar av egen design.
Testa och kalibrera radiofrekvens (RF)
Azure Sphere-chips kan använda Wi-Fi för att ta emot programuppdateringar och kommunicera med Internet. Om din produkt använder Wi-Fi och den innehåller antingen en chip-down-design eller en modul som inte är RF-certifierad, måste du utföra RF-testning och kalibrering för varje enhet. Den utrustning och de verktyg som behövs för den här uppgiften beskrivs i Utrustning och programvara för RF-testning och kalibrering i tillverkningsförberedelseuppgifterna.
RF Tools-paketet innehåller verktyg och ett C API-bibliotek för användning under testningen. Du kan använda C API-biblioteket för att programmera produktspecifika RF-inställningar i e-säkringar. Till exempel är e-säkringar programmerade för att konfigurera antennen och frekvensen, för att justera enheter för optimal prestanda och för att aktivera Wi-Fi-kanaler. Avsnittet RF-testverktyg beskriver hur du använder RF-verktygen.
Program-e-fuses för att aktivera Wi-Fi-kanaler
Azure Sphere OS väljer Wi-Fi-kanaler baserat på regionkoden som är programmerad till MT3620 e-säkringar vid förskjutningsadresser 0x36 och 0x37. Mer information om e-säkringar på MT3620 finns i mediatekdokumentet MT3620 E-fuse Content Guidelines .
Regionkoden är en ASCII-kod med två bokstäver. Azure Sphere OS använder regionkodinställningen i e-fuses för att leta upp regionen i den trådlösa Linux-regeldatabasen och väljer sedan de kanaler som tillåts för den regionen. Om ingen regionkod programmeras till e-säkringarna, i vilket fall e-säkringarna förblir inställda på 0x00 0x00, eller om tecknen "00" är programmerade, är operativsystemet som standard en konservativ uppsättning kanaler som vanligtvis tillåts i alla regioner. De kanaler som tillåts för regionen "00" anges i den trådlösa Linux-regeldatabasen.
Regionkodinställningen i e-säkringarna behöver inte matcha det land där enheten ska användas. Tillverkare kan välja valfri regionkod som mappar till en tillåten uppsättning kanaler för driftsregionen. Olika regioner och länder antar ofta liknande eller identiska förordningar, vilket kan göra det möjligt att använda regionkoder omväxlande.
Exempel: Om du vill instruera Azure Sphere OS att välja Wi-Fi-kanaler för regionen "DE" (Tyskland), program 0x44=D och 0x45=E i e-säkringarna på adresser 0x36 och 0x37. De tillåtna kanalerna för Tyskland, som hämtats från den trådlösa Linux-regeldatabasen, visas nedan. De flesta länder i Europeiska unionen (EU) tillåter samma uppsättning kanaler.
country DE: DFS-ETSI
(2400 - 2483.5 @ 40), (100 mW)
(5150 - 5250 @ 80), (200 mW), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
(5250 - 5350 @ 80), (100 mW), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5470 - 5725 @ 160), (500 mW), DFS, wmmrule=ETSI
# short range devices (ETSI EN 300 440-1)
(5725 - 5875 @ 80), (25 mW)
# 60 GHz band channels 1-4 (ETSI EN 302 567)
(57000 - 66000 @ 2160), (40)
Verifiera RF-konfiguration
Använd RfSettingsTool för att kontrollera att alternativkonfigurationsalternativen, till exempel målöverföringskraft, regionkod och Mac-adressen (Wi-Fi Media Access Control) har angetts korrekt. Dokumentationen för rf-inställningsverktyget innehåller mer information om hur du använder det här verktyget.
Verifiera Wi-Fi-kommunikation
Överväg att ansluta till en Wi-Fi-åtkomstpunkt för att kontrollera att ditt produktprogram kan kommunicera via Wi-Fi. Kontrollera att Wi-Fi-anslutningen inte har internetåtkomst, eftersom en uppdatering via luften kan inträffa om chipet ansluter till en Internetaktiverad åtkomstpunkt.
Om du vill ansluta en enhet till en Wi-Fi-åtkomstpunkt följer du anvisningarna på fliken Snabbstart (CLI). Om flera enheter är anslutna till datorn måste du inkludera parametern --device i kommandot azsphere device wifi show-status och kommandot azsphere device wifi add . Mer information om hur du använder azsphere-enhetskommandot med flera anslutna enheter finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet.
Efter Wi-Fi-testning bör du ta bort alla Wi-Fi-åtkomstpunkter som används för testning från chipet så att dessa inte är synliga för kunderna. Enhetsåterställning tar bort alla Wi-Fi-konfigurationsdata från chipet.
Konfigurera enheten för Ethernet
En Azure Sphere-enhet kan kommunicera via Ethernet. Enheten kräver ett externt Ethernet-kort och en brädkonfigurationsbild för kommunikation via Ethernet.
Om du vill konfigurera en Azure Sphere-enhet för Ethernet ansluter du ett Ethernet-kort till Azure Sphere-enheten enligt beskrivningen i Ansluta Ethernet-kort.
Två Ethernet-enheter stöds av Azure Sphere-operativsystemet.
- Mikrochip ENC28J60. Det här är ett 10Base-T-kort (10 mbps). Den kan kopplas med en LED-indikator i halv duplexhastighet eller utan en LED-indikator i full duplexhastighet. Seeed devkits är kabelanslutna för halvdubblade åtgärder.
- Wiznet W5500. Det här är en 100Base-TX-adapter (100mpbs). Den stöder en integrerad TCP/IP-stack och NIC-direktlägen, men Azure Sphere stöder endast NIC-direkt när du använder W5500 för internetanslutning. På grund av begränsningar i bussbandbredden kan det hända att MT3620-enheten inte kan uppnå full hastighet på 100 mbps.
Ethernet-gränssnittet aktiveras automatiskt när brädkonfigurationen har lästs in, enligt beskrivningen i Läsa in enhetsprogramvara och enheten startas om. Alla gränssnitt använder dynamiska IP-adresser som standard.
Slutför Azure Sphere-enheten
Slutförande säkerställer att Azure Sphere-enheten är i ett säkert tillstånd och är redo att levereras till kunder. Du måste slutföra enheten innan du skickar den. Slutförande omfattar:
Kör färdiga kontroller för att säkerställa att rätt systemprogramvara och produktionsprogram är installerade och RF-verktyg inaktiveras.
Ange enhetens tillverkningstillstånd för att låsa rf-konfigurations- och kalibreringsverktyg och förhindra säkerhetsöverträdelser.
Kör kontroller som är klara att skickas
Det är viktigt att köra kontroller som är klara att levereras innan du skickar en produkt som innehåller en Azure Sphere-enhet. Olika kontroller måste utföras för olika tillverkningstillstånd. Kontroller som är klara att levereras säkerställer följande:
- Enhetens tillverkningstillstånd är korrekt inställt för det tillverkningssteget.
- Azure Sphere-operativsystemet på enheten är giltigt och den förväntade versionen. Detta kan bara kontrolleras för enheter som ännu inte är i tillståndet DeviceComplete.
- Avbildningar som tillhandahålls av användaren på enheten matchar listan över förväntade bilder. Detta kan bara kontrolleras för enheter som ännu inte är i tillståndet DeviceComplete.
- Inga oväntade Wi-Fi-nätverk har konfigurerats på enheten. Detta kan bara kontrolleras för enheter som ännu inte är i tillståndet DeviceComplete.
- Enheten innehåller inga särskilda kapacitetscertifikat. För MT3620-baserade enheter kan detta bara kontrolleras på enheter som inte är i tomt tillstånd.
Olika kontroller är nödvändiga i olika tillverkningsstadier eftersom enhetens tillverkningsstatus avgör enhetens funktioner .
Vilka kontroller du kör beror också på om du utformar en modul eller en ansluten enhet. Som modultillverkare kan du till exempel välja att lämna chipet i tillståndet Tom tillverkning så att kunden i modulen kan utföra ytterligare radiotestning och konfiguration.
Använd device_ready.py för att utföra kontroller
Paketet Tillverkningsexempel innehåller ett verktyg som kallas device_ready.py, som utför ovanstående kontroller, efter behov för varje tillverkningstillstånd. Den bör köras för vart och ett av de tillverkningstillstånd som är relevanta för din enhet.
I följande tabell visas de parametrar som device_ready.py skriptet tar:
| Parameter | Description |
|---|---|
--expected_mfg_state |
Avgör vilket tillverkningstillstånd som ska kontrolleras och vilka tester som körs. Om den här parametern inte har angetts är standardinställningen "DeviceComplete". Om enhetens tillverkningstillstånd skiljer sig från det här värdet misslyckas kontrollen. |
--images |
Anger listan över avbildnings-ID:n (GUID) som måste finnas på enheten för att kontrollen ska lyckas. Listan består av bild-GUID:erna avgränsade med blanksteg. Den här parametern är som standard den tomma listan om den inte har angetts. Om listan över installerade avbildnings-ID:n på enheten skiljer sig från den här listan misslyckas kontrollen. Genom att kontrollera avbildnings-ID:t (i stället för komponent-ID:t) säkerställer den här kontrollen att en specifik version av en komponent finns. |
--os |
Anger en lista över versioner av Azure Sphere-operativsystemet. Den här parametern är standard för den tomma listan om den inte tillhandahålls. Om os-versionen som finns på enheten inte finns i den här listan misslyckas den här kontrollen. |
--os_components_json_file |
Anger sökvägen till JSON-filen som visar de OS-komponenter som definierar varje version av operativsystemet. För MT3620-baserade enheter heter den här filen mt3620an.json. Använd verktyget download_os_list.py för att ladda ned den senaste versionen. |
--azsphere_path |
Anger sökvägen till verktyget azsphere.exe. Om den inte anges är den här parametern standardinstallationsplats för Azure Sphere SDK i Windows. Använd endast den här parametern om Azure Sphere SDK inte är installerat på standardplatsen. |
--help |
Visar kommandoradshjälp. |
--verbose |
Ger ytterligare utdatainformation. |
Följande exempel är en exempelkörning av device_ready.py verktyget med följande argument:
--os 22.07--os_components_json_file mt3620an.json--expected_mfg_state Module1Complete
device_ready.py --os 22.07 --os_components_json_file mt3620an.json --expected_mfg_state Module1Complete
Checking device is in manufacturing state Module1Complete...
PASS: Device manufacturing state is Module1Complete
Checking capabilities...
PASS: No capabilities on device
Checking OS version...
PASS: OS '22.07' is an expected version
Checking installed images...
PASS: Installed images matches expected images
Checking wifi networks...
PASS: Device has no wifi networks configured
------------------
PASS
Ange enhetens tillverkningstillstånd
Känsliga tillverkningsåtgärder som att placera radion i testläge och ställa in e-säkringar för Wi-Fi-konfiguration bör inte vara tillgängliga för slutanvändare av enheter som innehåller ett Azure Sphere-chip. Azure Sphere-enhetens tillverkningstillstånd begränsar åtkomsten till dessa känsliga åtgärder.
De tre tillverkningstillstånden är följande:
Tom. Tillståndet Blank begränsar inte tillverkningsåtgärderna på ett chip. Chips i tomt tillstånd kan gå in i RF-testläge och deras e-säkringar kan programmeras. När chips levereras från kiselfabriken är de i tillståndet Tom tillverkning.
Module1Complete. Modul1Complete-tillverkningstillståndet är utformat för att begränsa de justeringar som användarna kan göra i inställningar för radiokonfiguration, till exempel maximala överföringskraftnivåer och tillåtna frekvenser. RF-kommandon kan användas tills Module1Complete har angetts. Att begränsa slutanvändares åtkomst till dessa inställningar kan krävas för att uppfylla regelprinciper kring radiomaskinvara. Den här inställningen påverkar främst tillverkare som behöver testa och kalibrera radiooperativparametrar.
Microsoft rekommenderar att du anger det här tillverkningstillståndet när radiotestning och kalibrering har slutförts. RF-kommandon kan inte användas när den har angetts. Module1Complete-tillståndet skyddar enheten mot ändringar som kan störa korrekt drift av radion och andra trådlösa enheter i närheten.
DeviceComplete. Tillverkningstillståndet DeviceComplete gör det möjligt för tillverkare av färdiga produkter att skydda enheter som distribueras i fältet mot ändringar. När en enhet har placerats i tillståndet DeviceComplete måste en enhetsspecifik kapacitetsfil användas när du utför programinläsnings- och konfigurationsuppgifter. Med funktionen fieldservicing kan du separat läsa in produktionssignerade avbildningar, men inte ta bort dem. Med funktionen för apputveckling kan du både läsa in och ta bort avbildningar separat.
Ange inte DeviceComplete för oavslutade enheter eller moduler (Wi-Fi-moduler, utvecklingstavlor och så vidare) som kan användas som en del av ett större system. Det här tillståndet begränsar tillverkningsaktiviteter som produktionslinjetestning, programvaruinstallation och konfiguration. Många CLI-kommandon är inte tillgängliga när DeviceComplete har angetts och därför måste vissa kontroller som är klara att skickas köras innan det här tillståndet anges. Begränsade kommandon kan återaktiveras med hjälp av en enhetsfunktion , till exempel funktionen fieldservicing , men endast för enheter som du har begärt, och därför är detta inte lämpligt för användning i en fabriksmiljö eftersom det kräver molnanslutning.
I följande tabell sammanfattas de enhetsfunktioner som finns för varje tillverkningstillstånd.
| Tillverkningstillstånd | Enhetsfunktioner |
|---|---|
| Tom | enableRfTestMode, fieldServicing och de som antingen läses in separat eller skickas med en åtgärd, enligt beskrivningen i Enhetsfunktioner. |
| Module1Complete | fieldServicing och de som antingen läses in separat eller skickas med en åtgärd, enligt beskrivningen i Enhetsfunktioner. |
| DeviceComplete | Endast de som antingen läses in separat eller skickas med en åtgärd, enligt beskrivningen i Enhetsfunktioner. |
När tillverkningen är klar använder du kommandot azsphere device manufacturing-state update för att ange tillståndet DeviceComplete:
azsphere device manufacturing-state update --state <desired-state> [--device <IP-address or connection-path>]
Kommentar
Om flera enheter är anslutna till datorn inkluderar du parametern --device för att identifiera målenheten med IP-adress eller anslutningssökväg. Mer information finns i Ansluta varje Azure Sphere-chip till en dator på fabriksgolvet.
Viktigt!
Att flytta ett chip till tillståndet DeviceComplete är en permanent åtgärd och kan inte ångras. När ett chip är i tillståndet DeviceComplete kan det inte ange RF-testläge. Dess e-säkringsinställningar kan inte justeras. Wi-Fi-inställningar, uppdateringar av operativsystem och installerade program kan inte ändras utan att enheten krävs och en enhetsfunktion används. Om du behöver återaktivera funktioner på ett enskilt chip som enhetens funktioner inte återaktiverar, till exempel i ett scenario med felanalys, kontaktar du Microsoft.