Olimex ARM-USB-TINY + Windows 7 + openOCD

Als ik het zo begrijp van Olimex moet je de drivers bij FTDI vandaan halen maar dan wel met de vid/pid ( PID: 0x0004, VID: 0x15BA) van Olimex installeren.
Als je in de devicelist bij windhoos kijkt welke vid/pid geeft hij dan aan?
Als ik het goed heb begrepen heeft FTDI de drivers die de kopieen blokkeerde weer teruggetrokken door de vele klachten van gebruikers.

Lees plezier : http://www.circuitsonline.net/forum/view/message/1659754#1659754

Die drivers zijn voor zover ik weet niet terug getrokken, maar zitten alleen niet meer in de automagische winshit updates. Als je ze download krijg je voor zover ik weet gewoon de drivers met dit gedrag.

Nou kent windows vast geen lsusb. Prik het ding eens in een Linux doos en kijk wat die roept. Dan heb je in elk geval de VID/PID. Kijken of die matched met je driver.
Zo nee, dan kun je de PID/VID aanpassen. Winshit begint dan wel weer te zeuren over een unsigned driver.
Je kunt ook de IDs in de programmer aanpassen, maar het zou zomaar kunnen dat de software de programmer niet meer vindt. FTDI levert ook een DLL om met dat spul te kletsen - geen VCP dus. Aangezien jij nergens een COM poortje opgeeft, neem ik aan dat het Olimex spul deze manier van kletsen gebruikt. Dan moet je dus van de programmer af blijven.

Maar goed... Kijk eerst eens wat de VID/PID is. Ik verwacht dat dat goed gaat, anders had je ze ook niet in de device list gezien.

De programmer is gebaseerd op de FT2232 chip.
Met het inpluggen van de programmer heb ik geen internet connectie en cancel ik de automatische windows install.

Ik gebruik de Zadig tool om de recente WinUSB drivers te installeren.
Dat doe ik voor beide interfaces 0 en 1 (2stuks in de FT2232 chip)

Bij driver details zie ik de juiste pid en vids staan, wel is het de vraag of dat de id's van de driver zijn of van de chip.

Ik gebruik nu openocd 0.8.0
Van een Duitser heb ik de juiste board en target configs gekregen.

http://openocd.zylin.com/gitweb?p=openocd.git;a=blob_plain;f=tcl/board/olimex_sam7_la2.cfg;h=89d2b5a592d78a81e7f855afc7bf1a528c715b33;hb=890c020bdaf99978a73eccb42f3051d074202ce6
http://openocd.zylin.com/gitweb?p=openocd.git;a=blob_plain;f=tcl/target/at91sam7a2.cfg;h=f7a0de2d69350ec89965850218738e283ce3cc26;hb=890c020bdaf99978a73eccb42f3051d074202ce6

Maar nog altijd geen succes helaas.

Weet iemand of je de melding "Error: unable to open ftdi device: device not found in procedure 'init'" ook zou krijgen als je target board defect is of niet is aangesloten?

Het board heb ik voor een prikkie via ebay gekocht van Olimex (althans iemand die zich Olimex co.uk noemt)
Het board is duidelijk met de hand gesoldeerd, dus fouten daarin zou ook nog aannemelijk zijn.

Op de programmer zie ik overigens geen ledje knipperen.
Wel brandt hij constant heel erg zwak, meer vanwege een lekstroompje denk ik.

Je spreekt jezelf tegen:

De printplaat van de programmer ziet er ook perfect uit.

Het board is duidelijk met de hand gesoldeerd, dus fouten daarin zou ook nog aannemelijk zijn.

Maar goed... Dat zal het probleem niet zijn - als die FTDI chip zich bij M$ meldt, dan zal dat stukje wel werken.

Je zegt dat je VID/PID ziet staan. Voor zover ik weet, maakt het niet uit of die uit de driver of uit de chip komen. Windhoos matched de driver met wat het het chippie roept. Tenzij die installatie echt de weg kwijt is, zou je verwachten dat die (dus) hetzelfde zijn.

De driver-die-fakes-molt doet dat in mijn beleving door VID/PID op 0/0 te zetten. Niks wat echt stuk is dus, maar het device wordt niet meer herkend. Als er bij jou nog wel een driver geladen wordt, dan lijkt me dat niet het geval.

Een 'zadig tool' ken ik niet. Tot op heden heb ik voor FTDI drivers gedownload, spul uitgepakt, hardware erin prikken, winshit 2x vertellen waar het spul staat en dat was het. Vanaf de meest recente versie (2.12) lijk je een executable te krijgen. Als je die eerst even uit pakt, werkt het ook nog op de 'klassieke' manier.

Verder blijf ik bij het advies om het ding eens in een Linux doos te prikken en kijken wat lsusb roept (Knoppix??). Voor winshit was er 'usbview'. Geen idee of dat nog bestaat en nog werkt. Dan heb je in elk geval enig idee welke IDs er op de bus zwerven, ook als het spul problemen met drivers heeft.

Openocd ken ik ook niet (ik weet eigenlijk best weinig ). 'open' impliceert open source. Je zou in de source moeten kunnen kijken welke VID/PID daar gebruikt wordt. Verder *denk* ik dat het spul D2xx communicatie doet (anders had je wel een com poort nummertje in moeten stellen). In mijn beleving heb je daar een dll voor nodig, als ik het wel heb ftd2xx.dll. Als je daar een bejaarde versie van hebt (en die vindt openocd toevallig als eerste), dan zou dat ook nog een verklaring kunnen zijn.

Dan nog een open deur voor die FTDI chips. Ik ken alleen de 'single' USB-UART conversie. In mijn beleving heb jij de dual. Dit is gebaseerd op de single. Hoe het precies werkt zonder hub weet ik niet, maar het ding installeert meen ik 2x zoveel drivers. Zal wel ergens i de USB spec staan.
Normaal gesproken installeer je per 'device' 2 drivers: 1 voor de D2xx communicatie en daarop een VCP driver (dat kun je opgeven in de D2xx config... of die VCP geladen moet worden).
Als je alleen die D2xx drivers laat laden, dan *denk* ik dat dat genoeg moet zijn (omdat je nergens com poortjes op geeft).
Als je er ook de VCP drivers bij stopt, dan kun je ook met een terminal (TeraTerm, putty) bij de UARTs. Of je er zinnige communicatie mee kunt, is wat anders, maar je kunt in elk geval kijken of die de boel wel kunnen connecten.

In mijn ervaring, 'bijt' een overbodige VCP driver D2xx communcatie niet. Wat natuurlijk wel kan, is dat die VCP door 'iets' op jouw machine geclaimed wordt (het zal niet de eerste keer zijn dat winshit een stuk hardware voor een mouse aanziet) waardoor D2xx iets als 'device busy' ofzo terug krijgt. Vandaar: kijk eens of je er met een terminal en een VCP driver wel bij kan.

LED die heel zwak brandt: dat is altijd raar. Waarschijnlijk heb je wel een schema. Kijk eens waar dat ding z'n voeding vandaan haalt. FTDI doet power handling normaal netjes: vragen aan het OS of je meer dan 100mA mag trekken, melden hoeveel en als het OS dat leuk vindt, dan pas de 'load' inschakelen (ze specificeren er zelf een NDT456P of een Micrel MC2025 oid. voor (nummertjes uit m'n hoofd, hoop dat ik goed zit).
Zou het kunnen dat die foutmelding je op het verkeerde been zet? FTDI chippie doet het wel, maar de power gaat niet aan waardoor het 'achterland' niet bereikbaar is? Kijk eens in de source wat die foutmelding precies triggert...
Of je die foutmelding krijgt als het board niet aangesloten is... kun je natuurlijk makkelijk proberen

Verder zie *ik* in die config files niks wat met FTDI te maken zou moeten hebben. Dus verwacht niet dat daar je probleem zit (aangenomen dat de foutmelding die je krijgt de lading dekt)

Op 21 november 2014 12:15:42 schreef EricP:
Je spreekt jezelf tegen:[...][...]Maar goed... Dat zal het probleem niet zijn - als die FTDI chip zich bij M$ meldt, dan zal dat stukje wel werken.

Ik bedoel daarmee dat de printplaat van de programmer er perfect uit ziet, maar de printplaat van het ARM board dat ik wil programmeren niet.

Ik moet inderdaad geen COM ports instellen etc.
Bij het inpluggen ziet hij wel 2 interfaces.
In principe zou ik aan 1tje al genoeg hebben denk ik.

Ik vertrouw het ARM board niet heel erg, dus vandaar dat ik me afvroeg of het loskoppelen van een programmer dezelfde soort error zou geven.
Want als mijn ARM board dusdanig stuk is dat het vergelijkbaar is met een losgekoppelde programmer, dan is de error wel te verklaren.

Ik zou inderdaad eens in de INIT functie van openOCD moeten kijken wat de error precies trickert.
Het zal niet voor het eerst zijn dat een error message niet helemaal de lading dekt.

Ik zou ook nog de FT chip kunnen proben of hij probeert te communiceren met het ARM board.

Een andere optie is, een geheel andere ARM dev toolchain gaan gebruiken, maar dat kan nog wel eens prijzig gaan worden.

Waarin ontwikkelen jullie ARM chippies?

Em::Blocks en dan eigenlijk alleen met Stm32 en Nordic arm processors.
ST heeft een zeer uitgebreid Discovery kit/Nucleo programma dat al begint bij €8,- , allemaal met ingebouwde Swd debugger.

Op 21 november 2014 14:52:49 schreef 2N3055:
Em::Blocks en dan eigenlijk alleen met Stm32 en Nordic arm processors.
ST heeft een zeer uitgebreid Discovery kit/Nucleo programma dat al begint bij €8,- , allemaal met ingebouwde Swd debugger.

Mooi spul, ik sta wel op het punt om olimex meuk vaarwel te zeggen.
Ik zoek dus een betaalbaar board en omgeving in de richting van een ARM7 of ARM9 of hoger.
In elk geval moet het FreeRTOS of Embedded linux kunnen draaien.

UPDATE Ik had ook nog een LPC2103 board liggen met JTAG, maar ook zonder succes.

[Bericht gewijzigd door spruce op vrijdag 21 november 2014 18:14:51 (14%)]

Helaas op een ubuntu 1404 installatie dezelfde error.
Lijkt er dus toch op dat de programmer is overleden.

Met lsusb command zie ik hem op linux ook verschijnen, echter connecten lukt niet.

2 verschillende target boards geprobeerd.

Zonde van al mijn tijd, want ik bleek gelijk te hebben.
De programmer is gewoon stuk.

Vandaag een nieuwe Olimex ARM-USB-OCD-H programmer gekocht.
Binnen no-time telnet verbinding werkend met het target board.
En even een LED blink .bin file erin geschoten.

Nu nog even uitvogelen waarom ik het target niet zie in Eclipse.
Ik zal handmatig een configuratie moeten aanmaken verwacht ik.

Mooi dat het werkt. Beetje offtopic, maar ik gebruik zelf Coocox met zo'n STM bordje, werkte allemaal zonder teveel rompslomp.