Sok helyen lehetett olvasni hamis chipekről, alkatrészekről, újként eladott kitermelt részegységekről. Az ATMega328 chipből volt aki üres tokot vett, hallani lehetett futószalagról selejtezett hőfokhibás Dallas chipekről, átszitázott Intel processzorokról. És legtöbbször azt gondoljuk, hogy ilyen velünk nem történhet meg. Pedig az ördög nem alszik….
A TavIR WebShopban az eszközök tételesen ellenőrzésre kerülnek – olyan nincsen, hogy valami műszaki adatlap és minőségellenőrzés nélkül hagyná el az íróasztalt. De a beérkezési útvonalba időnként be-be csúsznak oda nem való eszközök… Legutóbb az Arduino Nano került a horogra.
A tünet
Az áramkörök a tesztelés első lépésében rövidzár és minimál-működési tesztnek vannak alávetve. Egy labortáp, egy 5V-os USB adapter csodákra képes… Felmerült, hogy a PC USB felületén is lehetne ezeket a teszteket indítani – ám ez inkább így egy orosz rulett. Az áramkör lehet, hogy rövidzáras, hibás, túlfeszültséget állít elő… Az első lépésben a tápfeszültség ráadása és a kiemelt helyeken a feszültség mérése történik meg: szűrőkondik, mikrokontroller tápfeszültségei, feszültségstabilizáló chipek. És persze kézzel kontakthőmérés – hátha valami rendellenesen forrósodik. Eddig minden a normál működés szerint: tápfeszültség visszajelző LED világít, kommunikációs LED felvillan, bootloader visszajelző LED villog.
A következő lépés a kommunikációs csatorna és/vagy tesztprogramok feltöltése. Itt az eszközök alapvető életjelei már megmutatkoznak. A kommunikáció általában USB felületű és a meghajtóprogramok telepítésével történik. Kicsit fura, mert a rendszerbe beállítható, hogyha FTDI chip jön a képbe, akkor az a COM3 portra települjön. Ez meg a COM42 lett. De végülis a driver fenn van, nagy hibát csak nem okoz.
A kommunikációs teszt egyszerű, hisz az Arduino Nano az áldozat: a LED villogtató programot töltsük fel. Az áldozat Windows XP egy múzeumi gépen (PII-350/512M/3G) – viszont méri az USB túláramot is! Ha meghal valamiért a gép – csak erkölcsi értéke van már…
A feltöltés során a szokásos a folyamat: Arduino-1.0.0 elindít, kommunikációs port és alappanel beállít, Examples – Basic – Blink kiválasztva és feltöltés…
Néhány villogás a Tx LED-en, chip bootreset-et jelző villogása, és a feltöltés sikeres! Működik!
Akkor bátorságpróba kész, mehet a Windows7 x64-re. Nyúzópróba folytatása… Szintén Arduino-1.0.0 keretrendszer és a panel kiválasztása, majd sorosport megadása. A minta szintén a már bevált Blink tesztprogram. Végül File – Upload…:
„Not in sync….”. Akkor a típushibák, amik szóba jöhetnek: hibás alappaneli eszköz vagy rossz sorosport lett kiválasztva vagy csak megint fennmaradt a BlueTooth sorosport…
Egyik sem. Na, bootloader újraégetése a beépített funkciókkal – hátha arra van a baj:
Ez legalább megy. Ahogy 1.0 alatt a közvetlen programozóval való LED-villogtató égetés is. USB-n keresztüli programozás azonban újra-meg-újra: „Not in sync…”
Gyanús a nyák…
Az ólommentes forrasztás rideg, törhet. Akár a furatgalván is…. Így nagyítóval a teljes lapot átnéztem, ahol hiba lehetne, átforrasztottam. Az eredmény sem maradt el: „Not in sync…” De legalább még él a lapka és nem füstöl.
De miért megy XP alatt és miért nem Windows7 x64 alatt?
Még egy próba – az összes családi gép már lassan elfogy… Netbook, Windows 7 Starter. Persze, hogy itt minden rendben…. Akkor szisztematikus rendszerteszt következik.
Driverteszt
Mindegyik gépen a legújabb driver. Hátha csak hibás a telepítés. Driver törlése, újratelepítés a www.ftdichip.com oldalról.
Az eredmény lehangoló: XP és Win7 starter alatt megy, Windows7 x64 alatt nem:(. Ellenpróbaként egy régi áramkört beraktam: minden rendszer, mindegyik driverrel rendben.
Akkor hardware tesztek jönnek…
Nullmodem
Akkor kezdjünk a túloldalt. Soros-USB átjáró ellenőrzésére a legegyszerűbb, ha a kijövő adatot visszaküldjük az illesztőbe. Így a PC oldalon egy terminálban a kiküldött adatot azonnal látjuk.
A kommunikációban zavaró AVR chip eltávolítására van egyszerűbb mód: tegyük Resetbe! Így azt használjuk ki, hogy a chip reset állapotában minden egyes I/O lába nagyimpedanciás bemenetté válik. Így egyszerűen a Tx-Rx kivezetést összekötöttem (hamár ott van a lábakon:) ). Persze a szakadás ellenőrzés, hogy ne menjek az erdőbe…
És a sokat tudó Bray++ terminal megnyitása, majd adatküldés:
És ami visszajön: <00>. Mintha a Tx-Rx összekötés GND-re lenne kötve – pedig kimérve semmi nem tűnik hibásnak. Á, biztos csak gerjed valami, vagy nem jó (esetleg a Windows7 x64-es latop USB-je zajosabb), így az egzaktabb megoldás felé nyitok: logikai analizátor kerül bevetésre. Itt sem jobb az eredmény 🙁
Menedékként és ellenpróbaként – a szériából egy másik darabot is kipróbáltam. Ugyanaz az eredmény. Egy régebbi kísérleti darabbal minden működik… Talán egy kondi, egy ellenállás… Ezeket is végigmértem, ahogy a kontrolláramkörön is. Nincs semmi eltérés. Azaz még ezek sem okozhatnak ilyen hibát…
Feltöltés figyelése
Ha már van logikai analizátor, akkor a feltöltés folyamatát is meg lehet vizsgálni. Ez a legegyszerűbb esetben három lábat jelent:
- Tx a kiküldött adatról
- Rx a visszajövő adatról és a
- Reset a chip újraindulásáról (DTR)
Az adat figyelése egyszerűen a lábakra csíptetéssel megoldható:
A probléma itt is tetten érhető. Csak két darab 00×0 érték kerül kiküldésre az FTDI felől az AVR chipre. És erre ugye válasz nem sok érkezik.
XP esetén a Arduinoban a log kiírást is lehet figyelni, így a kérdés-válasz teljesen jól követhető. Például a ChipID lekérdezése:
Érdekesség, hogy a logikai analizátorban a sorosport sebességét automatikusra állítottam és a visszakapott sebességérték:
- FT232RL → AVR (Rx): 57971 bps
- AVR (Tx) → FT232RL: 59259 bps
Az ATMega328 adatlapjával jó egyezést mutat a fellelt sebesség, mert ha 16 MHz-n járatom a chipet, akkor a névleges 57600 bps helyett 59259 bps sebességgel válaszol. A hiba ekkor a névleges 57600 bpshez képest ~1%. Bár az FTDI FT232RL esetén ezt 0.5% alatt kell tartani, a tapasztalat az, hogy 2-3% hibát a chip még tolerál. De a kommunikációs sebességbeli hiba meghatározása automatikusan történt viszonylag kis mennyiségű adatból (így ennek bizonytalanságát is figyelembe kell venni).
Kivégzés
A „Hogyan tegyünk tönkre egy Arduino-t 10 lépésben” cikksorozatot nem ezzel szándékoztam megírni. Így a korábbi tesztek eredménye alapján – minden mindegy alapon – az USB illesztőchipet kicseréltem. Jó az, ha van itthon forrasztópaszta, hőlégpáka és egyéb nemstandard hobbieszközök (tűzoltópokróc, tesla tekercs, szamovár…).
A chipből is volt. Csere után, mintha mi sem történt volna! Az áramkör azonnal működik….
….szameg!
A kiforrasztott chip félretéve jobb napokra – persze megjelölve. Így mehet a bonckés alá. Szerencsére van még eredeti tape-reel kiszerelésben, így a kontroll adott. A fénykép alatt a két chip azonos megvilágításban Kicsit beégett a kép, de így vált láthatóvá a – gyanús – FTDI chip):
Sok minden nem látszik. Mintha talán kicsit szürkésebb lenne a nem működő (felső Arduino Nano). A betűk, jelölések eltérése sem olyan égbekiáltó. Akár két külön gyártósorról is lejöhetett volna.
Sherlock Holmes kicsiben
A tapasztalat valahogy megint azt mondatja, hogy szélhámosok mindig vannak/lesznek. Es hogyan biztosítja be magát az ember? Ha mindennek utánaolvas és tesztel. A minőségbiztosítást meg lehet tenni papírok nélkül is, egyszerű folyamatokat modellezve. Ez a hiba volt az utolsó csepp, így körbeért a TavIR minőségbiztosítási rendszere. Legyen szó levelezésről, határidőkről és bontatlan eszközökről…
De vissza a nyomozáshoz…
Az USB eszközök árulkodók tudnak lenni. Minden jellemzőt kifecsegnek magukból. És ha ezt olyan szoftver felé teszik, ami körüljárja – akkor lebukás van. Miután a hiba előkerült, már könnyebb volt a dolgom. Sejtettem mit keresek: a chipet hamisítják. Ez lehet egy átszitázott illesztő-alkatrész, egy gyártósorról minőségbiztosításon megbukott leesett darab vagy egy átszitázott mikrokontroller…
Mintha tűt keresnék a szénakazalban… De ha van egy-két mágnes, könnyebben lehet haladni…
Az usbview sokat nem mondott. A chip – szerinte – FTDI, bár csak azt mondja vissza, amit beleírtak, hogy azt mondja vissza. De tuti nem csak én vagyok így, hanem mások is belefutottak ilyen problémába…
A bejegyzések inkább fórumtapasztalatok, 1-1 felszínes leírás van itt-ott. Az eredmény sem kecsegtet semmi jóval…
A lepel lehull
Az FTDI chippel teljesen megegyező lábkiosztású, de csak közel funkció-azonosan a Prolific PL2303 jelű chipje érhető el. Míg az FTDI 2-4$ körüli áron beszerezhető, addig a PL2313 eszköz 0.5..1$ körül van. Talán licensz-problémák, utángyártás áll az ügy mögött. A Prolific más USB VID/PID azonosítóval bír, de miből áll átírni? És driver oldalról is csereszabatosnak tűnnek a chipek. Talán a piacvesztést, a gyengébb kivitelt elégelte meg az FTDI. És a 64-bites rendszerbe tett egy védelmi csavart…
Hány FT232RL-nek kinéző, átszitázott áramkör lehet beépítve, ahol Windows XP fut és nem is sejtik, hogy egy szoftvercsere hány ősz hajszálat fog okozni….
Tanulság
Van ilyen? Talán csak az, hogy nem minden chip az, aminek látszik. És majd’ mindenből van eredeti és ennek a jobb/rosszabb másolata. Bosszantó, hogy kész, komplett áramkörbe beépítve lehetett találkozni vele – és még nem is China/E-bay volt a beszerzés forrása. Ott sokkal szebb hirdetések/hamis áramköri lapkák fordulnak elő!
Óvatosan a külföldi rendelésekkel, mert aztán mandarin / szuahéli nyelven írhatjuk a reklamációt!
De, ha belefutsz egy problémába, akkor nem biztos, hogy a hiba benned van. Szisztematikus hibakereséssel mindennek a végére lehet járni…
Kiegészítés egy kicsivel később…
Az eszmefuttatásból is látszik, hogy nem egyszerű a megoldás. Azonban az eredmény még kiábrándítóbb, mint az innen látszik elsőre….
A cikk megjelenése után majd egy évvel a lepel végleg lehullt – bár nem lehetünk teljesen boldogok: → Hamis a baba II.
