Az Arduino 1.6.4….1.8.19 és a Arduino IDE 2.3.3 kiadású keretrendszerben az ESP8266 modulokra történő programfeltöltéskor, – az esptool.py használatakor – gyakran jelentkezik a PermissionError hiba. Ez a hiba akár telepített, akár portable módban használva az Arduino keretrendszert – bármelyik kiadású ESP8266 kiegészítővel – előfordulhat. Leginkább az ESP8266 kiegészítés telepítése után már az első mintaprogram feltöltésénél és kipróbálásakor jelentkezik. A hibát sokszor a Windows 11 rendszernek vagy a telepítési folyamat problémájának véljük… A probléma azonban ennél jóval összetettebb – ugyanakkor egyszerű megoldással.
Ebben a cikkben próbáltam összefoglalni az ok-okozatot, a tapasztalatot és a megoldást. Ugyanakkor a hibakeresés során a folyamatot is igyekszem bemutatni, hogy hogyan lehetett a hibaokokat szűkíteni és persze cikk végén megoldás is előkerül.
Az irodalomkutatás során számos zsákutca, ötletbörze volt – amik a megoldástól csak távolabb vittek. Elemzés és forrásmeghatározás szintű leírást sehol nem találtam – így okulásul készült ez a részletes step-by-step mini-tanulmány….
Bevezetés az esptool.py hibához: PermissionError és port konfigurációs problémák
Az esptool.py eszköz alapvető fontosságú az ESP8266 és ESP32 mikrokontrollerek programozása során – ugyanis ez a python nyelven írt program felel a firmware feltöltéséért a mikrokontroller memóriájába. Az Arduino integrált fejlesztőkörnyezetben az ESP8266/ESP32 kiegészítés is ezt a programkészletet használja.
Egy új telepítésű Windows 11 rendszerre az Arduino 1.8.13 keretrendszer került fel és az ESP8266 kiegészítésből a 2.7.4 kiadás. A tesztelési modul a D1 mini ESP8266EX kiadása (az ESP12 fémtokos modullal). A blink (LED-villogtató) mintaprogram feltöltésekor már az alábbi hibaüzenet fogadott:
„A fatal esptool.py error occurred: Cannot configure port, something went wrong. Original message: PermissionError(13, ‘Egy rendszerhez csatlakoztatott eszköz nem működik.’, None, 31)”.
Más alaplap esete
A sikertelen feltöltés után – a hibaüzenet alapján hibás USB illesztőchipre tippelve – a D1 mini Pro/16 áramkör került elő – erre a feltöltés azonnal sikeresen megtörtént! Ellenpróbaként egy régebbi fejlesztői környezetben (szintén Arduino 1.8.13 portable és ESP8266 2.7.4 támogatás – de Windows 10 alatt) a hibásnak vélt áramköre a blink mintaprogram azonnal, hiba nélkül felmásolásra került és működött!
És akkor jött néhány keresztpróba: Arduino keretrendszer frissítés 1.6.13 -> 1.6.16 vonalon, ESP8266 támogatás oda-vissza cseréje a 2.7.4 – 3.0.0.- 3.1.2 háromszögben és a feltöltési kísérlet a D1 mini és a D1 mini Pro/4 és D1 mini Pro/16 lapokra.
| Arduino 1.8.13 | Arduino 1.8.16 | |||||
| 2.7.4 | 3.0.0 | 3.1.2 | 2.7.4 | 3.0.0 | 3.1.2 | |
| D1 mini | + / – | + / – | + / – | + / – | + / – | + / – |
| D1 mini Pro/4 | +/+ | +/+ | +/+ | +/+ | +/+ | +/+ |
| D1 mini Pro/16 | +/+ | +/+ | +/+ | +/+ | +/+ | +/+ |
A Win10 / Win11 tesztek eredménye
A gyanu árnyékában
Az eddigi teszteredmények alapos elemzése alapján a figyelem az operációs rendszer és annak különböző verziói közötti különbségekre irányult. Elsőként egyértelműen megfigyelhető volt, hogy míg a Windows 10 környezetben a feltöltés hibátlanul működött, addig Windows 11 alatt a hiba rendszeresen előfordult. Ez a különbség eleinte az operációs rendszer újabb verziójának hibájára utalt, ami logikus következtetésnek tűnt, hiszen a Windows 11 és az Arduino platform között több kompatibilitási probléma is dokumentálva volt már. Azonban, hogy kizárjam a Windows verzió közvetlen hatását, további tesztek következtek.
Az ideális megközelítés az volt, hogy egy tiszta, új telepítésű Windows 10 operációs rendszert hozzak létre, ezúttal egy virtuális gépen. A környezet friss telepítésként tartalmazta az Arduino 1.8.13 portable verzióját, valamint az ESP8266 kiegészítést, amelyekhez az illesztőprogramokat automatikusan telepítette a rendszer. Ezen a konfiguráción ugyanazt a mintaprogramot próbáltam feltölteni az ESP8266 modulra, mint korábban. Az eredmény meglepő volt: a hibajelenség pontosan ugyanúgy jelentkezett, mint a Windows 11 alatt. Ez egyértelműen kizárta, hogy az operációs rendszer verziója önmagában felelős lenne a hibáért.
Ezen a ponton merült fel az első komoly kérdés: ha nem az operációs rendszer a hiba oka, akkor mi lehet az? A neten fellelhető legtöbb hibaelhárítási javaslat – mint például a rendszer újratelepítése, az illesztőprogram frissítése vagy az Arduino IDE rendszergazdaként történő futtatása – mind kipróbálásra került, de egyik sem hozott megoldást. Az is felmerült, hogy talán a portable telepítési mód jelenthet problémát, ezért egy újabb teszt során normál telepítéssel is felkerült az Arduino és a kiegészítői – de a hiba változatlanul fennállt.
Hogy a problémát még alaposabban körüljárjam, a tesztkörnyezetet kiterjesztettem az újabb Arduino IDE 2.3.3 verzióra is. Egy újabb virtuális gépre telepített Windows 10 rendszerrel és az Arduino IDE 2.3.3 kiadásával ismét végigfutottam az ESP8266 variációkat. Az eredmények azonban nem változtak: a hiba továbbra is reprodukálható volt.
A felismerés
Felmerült annak lehetősége is, hogy az alappanel maga, vagy annak hardveres kivitele lehet hibás. Ezt alapos ellenőrzésnek lett alávetve. Az ESP8266 alapú D1 mini lapon jelentkező hibát követően egy NodeMCU alaplapot próbáltam ki, amely szélesebb modulként kínál alternatív tesztlehetőséget. Az eredmény hasonló volt: a hibajelenség ugyanúgy jelentkezett. Azonban érdekes módon, amikor az ESPDuino alaplapot használtam – amely szintén ESP8266-alapú, de kissé eltérő hardveres konfigurációval –, a feltöltés problémamentesen sikerült.
Mi a közös azokban, ahol a hibára futottam? Ezek szépen sorban:
- –
ESP8266EX chip(de ez volt minden lapnál) - – CH340 illesztőcsalád (részben hol megy, hol nem)
- – Új (friss telepítés)
Minthogy az operációs rendszer 64 bites verziójú kísérletei voltak. Esetleg még ez okozhat valamit. A gyanú a CH340 chip illesztőcsaládra terelődött! A kipróbált eszközöknél az alábbi képek születtek (ESPduino, D1 mini és NodeMCU lapok):
A D1 mininél hibára futott, a többi lapnál nem!
A megoldáshoz vezető út és a további szűkítés
Az összeállítás szerint ami már látszik, hogy az alábbi együttállás szükséges a feltöltési hiba reprodukálásához:
- CH340 eszközkezelő fizikai IC-ből a felirat nélküli kiadás
- Új telepítésű rendszer → új kiadású CH340 illesztő/driver
Következmény: az új telepítésű rendszerek esetén a meghajtóprogram is a legújabb!
Ez az eredmény arra utalt, hogy a hiba nem egyszerűen a feltöltés folyamatából ered, hanem szoros összefüggésben áll a használt hardver specifikus tulajdonságaival. Különösen figyelemreméltó volt, hogy a probléma olyan modulokon jelentkezett csak, amelyek a CH340 USB-illesztő chipet használtak, és a D1 mini esetében kizárólag az ESP8266EX processzorral kombinálva.
Ezek alapján már a megoldás erősen körvonalazódik!
A megoldás és az ellenpróba
Az USB illesztésért többféle eszköz felel a kísérletben – az USB-Serial illesztő lehetett a Silabs CP210x illetve a WCH CH34x chipcsalád valamelyik tagja. A CH34x család tagjain van a gyanu, azon belül is a felirat nélküli kiadáson. Ezen IC esetén a fotókat megszemlélve és a CH340 adatlapot elővéve gynús még, hogy nincsen mellette kvarckristály – azaz a belső órajelforrású kiadás lehet az áramköri lapon: a CH340 adatlap szerint ezek a CH340C, CH340E és CH340B alváltozatok valamelyike. A lábkiosztás alapján a kvarcnélküli – de a feliratos CH340G-vel megegyező lábkiosztású a CH340C típusjelű áramkör!
Az eddig végzett kísérletek nagyon valószínűen rávilágítottak arra, hogy a hibát a hardver és a szoftver közötti specifikus kompatibilitási problémák okozzák, különösen a CH340C chip és az újabb illesztőprogramok között. A következő lépés ennek a feltételezésnek a további vizsgálata volt, amely végül a hiba gyökerének pontos meghatározásához és a megoldás kidolgozásához vezetett.
Eszközillesztő ellenőrzése
De mi az az ellenpróba? Hiszen a chipet nem szívesen forrasztgatja ki/be az emberfia. Így marad az egyszerűbb, másik megoldás – a drivert teszteljük le. Az egyes kiadások, amik szóba kerültek (Windows eszközkezelőből a verziószámok egyszerűen megállapíthatóak):
Az eszközkezelő megnyitása: Windows+R gombnál a futtatási ablakba a devmgmt.msc utasítást kell beírni és a megjelenő listában a jobb egérgombbal való rákattintásnál a tulajdonságokat választani.
És a megjelenő ablakban az Illesztőprogram fület kell kiválasztani
A képen a 2024. évi kiadás és a 3.4.2014.8 látszik (2014/08 hó). Ezzel a meghajtóprogrammal működik a feltöltés minden chip esetén. Az új kiadásnál pedig az alábbi fogad:
De mi is az a PermissionError a COMx port esetében?
Ez a PermissionError hibaüzenet azt jelzi, hogy a feltöltésért felelős esptool.py program valamiért nem tud hozzáférni egy adott soros porthoz. Ennek általában az az oka, hogy a számítógép futó programja nem tudja megfelelően beállítani a portot a kommunikációhoz, mivel nincs megfelelő jogosultsága, vagy egy másik program már használja azt. A másik program használja – az kizárható volt – sem soros terminál ablak, sem adatfeldolgozó programunk nem futott. Ugyanakkor fontos, hogy az Arduino IDE 2.3.3 esetén az esetlegesen nyitva maradt soros terminál mindenféle gondot tud okozni! Érdemes ehhez a →Gyakori hibák az Arduino 2.3.3 Serial Monitor használatakor – Előzmények és megoldások cikket elolvasni.
Hibaelhárítás: a PermissionError elhárítása lépésről lépésre
Az előzőekben a hibakezelése során már sikerült megállapítani, hogy az USB illesztő chip és a meghajtóprogram együttállása okozza a hibát. A chipcsere körülményes, gyakorlatot kíván és nem is biztos hogy elsőre sikerül. Így maradjon a másik út – a meghajtóprogram frissítése a régi verzióra (azaz downgrade következik).
A régi CH340 driver letöltése és telepítése
A régebbi CH340 driver verzió letöltése segít elkerülni a kompatibilitási problémákat, amelyek biztosan előfordulnak a 3.9.2024.09-es verziónál.
Driver letöltése: Keressünk egy megbízható forrást, például a gyártó oldaláról, és töltsük le a régebbi (3.4 vagy 3.5) CH340 drivert. Vagy egyszerűen TavIR oldaláról is letölthetjük a →Számítógép USB port – soros illesztés (és minden ami a buktatókkal együtt jár) cikkből vagy közvetlenül a TavIR oldalról: →CH340/CH341 (WCH) driver.
Telepítés: A driver kicsomagolása után a Windows könyvtárban a telepítőkészlet érhető el, míg egy magyar nyelvű lépésenkénti telepítési útmutató. A telepítőkészletet futtatva a frissítőablak jelenik meg – közben a futtatást és a kibontást is hagyjuk jóvá.
Fontos! A telepítés során az eszköz legyen a PC-re csatlakoztatva, különben a driver frissítése hibára fut!
A telepítés végén a meghajtóprogram frissítése megtörtént. Ezt az Eszközkezelőben a korábban írt módon le is ellenőrizhetjük.
Tesztelés
Miután a régi CH340 driver telepítése befejeződött, ellenőrizni kell, hogy a hiba megszűnt-e. Néha szükséges a driver teljes betöltéséhez a számítógép újraindítása (ez több felhasználó által használt Windows rendszernél szükséges).
- Csatlakoztassuk az ESP8266 modult a számítógéphez.
- Arduino beállítások: A Tools menüben válasszuk ki a megfelelő ESP8266 modellt és a hozzá tartozó COM portot.
- Firmware feltöltése tesztként: Próbáljunk meg feltölteni a legegyszerűbb firmware-t – a LED villogtató programot (Blink, azaz a File→Examples→ESP8266→Blink). Ha a feltöltés sikeres, a hiba megoldódott!
Összefoglalás
Az Arduino keretrendszer és az Espressif ESP8266 modulok használata során gyakran előforduló PermissionError hiba oka a WCH CH340 illesztőprogramjának és bizonyos hardververzióknak (különösen a CH340C chipnek) az inkompatibilitása. A cikk részletes hibakeresési folyamata során mutatja be, hogy a problémát az újabb illesztőprogramok (pl. 3.9.2024.9 verzió) okozzák, melyek nem minden esetben kompatibilisek az ESP8266 fejlesztőkészletek CH340C illesztőjével.
A megoldás egyszerű és hatékony: telepítsd a régebbi, stabilabb CH340 driver egyik verzióját (például a 3.4.2014.8 kiadást). Ez a driverfrissítés gyorsan megoldja a hibát, anélkül hogy bonyolult rendszerkonfigurációra vagy hardveres chipcserére lenne szükség. A részletes útmutató a hibafeltárás és a telepítés lépéseiről remélhetőleg sokat segít az Arduino projektek zavartalan folytatásához….
Gyakran ismételt kérdések (GYIK)
Ebben a fejezetben a gyakori kérdések kerülnek leírásra – ha a cikket nem szeretnéd végigolvasni és azonnali, gyors eredményre van szükséged.
Mi okozza a PermissionError hibát az Arduino IDE-ben ESP8266 modulok használatakor?
A hiba oka az újabb CH340 illesztőprogram és bizonyos ESP8266 hardverek, például a CH340C chip verziók inkompatibilitása. A megoldás a CH340 driver egy régebbi, stabil verziójának (pl. 3.4.2014.8) telepítése, amely kompatibilis a CH340C/ESP8266 modulokkal.
Hol találom meg a megfelelő CH340 driver letöltési linkjét?
A megfelelő verziók letöltéséhez látogasd meg a cikkben található ajánlott linkeket vagy keresd fel a gyártó hivatalos oldalát.
Miért működhet az ESP8266 egy másik számítógépen hiba nélkül?
Ez valószínűleg azért van, mert a másik számítógépen egy régebbi CH340 driver verzió van telepítve, amely kompatibilis a moduloddal. A hiba leggyakrabban a CH340C chipet tartalmazó lapoknál fordul elő, különösen, ha azokon belső órajelforrást használnak (kvarckristály nélkül).
Mi a teendő, ha a driverfrissítés után sem szűnik meg a hiba?
Ellenőrizd, hogy a megfelelő driver verzió van telepítve, és indítsd újra a számítógépet. Ha a probléma továbbra is fennáll, nézd át az Arduino IDE beállításait, vagy próbálj ki egy másik USB-kábelt vagy portot.
Források
– ESP8266 használati útmutató és példák [Arduino.cc]
https://www.arduino.cc/en/Tutorial/ESP8266
– CH340 Driver Windows 11 és Windows 10 [Device Drivers]
https://oemdrivers.com/usb-ch340
– CH340 chip részletes adatlap [WCH]
http://www.wch.cn/products/CH340.html
– Arduino IDE verziók és ESP modulok kompatibilitása [GitHub (Arduino-ESP8266)]
https://github.com/esp8266/Arduino
– CH340/CH341 Windows soros port illesztőprogram telepítése [WCH]
https://www.wch.cn/downloads/CH341SER_EXE.html
– CH340 illesztőprogramok Windows, Mac és Linux rendszerekhez [SparkFun]
https://learn.sparkfun.com/tutorials/how-to-install-ch340-drivers/all
