Hi Leute !!!
Da ich bei einem ATTiny45 auch den Reset-Pin als I/O nutzen möchte, habe
ich mir den Fastboot Bootloader entsprechend angepaßt, kompiliert und
auf den µC übertragen. Für den Programmer nutze ich die von Peter
Dannegger vorgegebene Schaltung (Siehe Anhang!), wobei ich statt der
4750 Ohm Widerstände, 4700 Ohm und statt der 1N4148 Dioden, 1N4002
genommen habe. Die Bauteile hatte ich halt noch vorrätig und nach
Auskunft hier im Forum, sollte es damit eigentlich auch funktionieren.
Das Ganze ist dann über einen USB2TTL-Konverter (PL2303HXA Chip) mit dem
PC verbunden. Unter Windows 7 sind die entsprechenden Treiber von
Prolific installiert. Als Benutzeroberfläche für die Datenübertragung
zum µC nutze ich den UpdateLoader.
So, bis dahin also keine Probleme. Nur scheitert das weitere Vorgehen
dann leider schon am Verbindungsaufbau:
---------------------------------------------------
Firmware-Datei geladen (Test.hex)
Firmware-Update gestartet (170 Byte)
Fehler beim Firmware-Update, Ausführung abgebrochen
COM-Port öffnen
Verbindungsaufbau...
Fehler aufgetreten, Update abgebrochen!
---------------------------------------------------
Tja .... :-(
Der UpdateLoader führt also bei aktivierter "1-Wire Erkennung" die
eingestellte Anzahl an Verbindungsversuchen durch und bricht dann ab.
Aber wo fange ich jetzt mit der Fehlersuche an? Es existieren hier ja
eine ganze Menge Stellschrauben, an denen man drehen kann, angefangen
beim Bootloader selbst, wobei ich mir da ziemlich sicher bin, daß dieser
richtig konfiguriert ist, über die Schaltung bis hin zu den
Einstellungen im UpdateLoader und dem Konfigurationsmenü des
USB2TTL-Konverters im Gerätemanager (Baudrate, Datenbits, Parität,
Stoppbits, Flusssteuerung, FIFO-Puffer).
Ich hoffe, daß mir hier jemand weiterhelfen kann.
Grüße,
The SphereX
The SphereX schrieb:> Baudrate, Datenbits, Parität,> Stoppbits, Flusssteuerung, FIFO-Puffer).
wenn du direkt mit TTL-Pegeln arbeitest, musst du RX und TX des Adapters
invertieren (ka ob deiner das kann, der FT232 kann es). Die Dioden
brauchst du garnicht.
Ich habe gestern das gleiche Problem gehabt:
www.mikrocontroller.net/topic/345199
Danke erst mal für den Hinweis, aber das Vertauschen von TX und RX hat
leider auch nichts gebracht. Ich bekomme also nach wie vor keine
Verbindung zum µC :-( .
Woran erkenne ich denn, ob sich hier überhaupt was tut? Wie gesagt, bei
derartig vielen Stellschrauben, weiß man ja irgendwie gar nicht, wo man
bei der Fehlersuche anfangen soll.
Ich habe einfach mal die Pegel am µC gemessen:
--> ROT (5 V) --> VCC
USB2TTL --> SCHWARZ --> GND
--> WEISS RX (0 V) --> PB2
--> GRÜN TX (3,3 V) --> 10 kOhm --> PB2
> VCC: 4,90 V> PB2: 3,62 V> PB2: schwankend zwischen 3,47 V - 3,49 V während dem Verbindungsversuch
Läßt sich mit den Werten was die Problemlösung angeht evtl. etwas
anfangen?
Grüße,
The SphereX
> Woran erkenne ich denn, ob sich hier überhaupt was tut?
Häng das Oszi dran und schau Dir an was an dem Portpin ankommt und ob Du
sehen kannst ob der Bootloader versucht zu antworten (und ob diese
Antwort dann auch wieder ordentlich am RX-Pin der seriellen
Schnittstelle ankommt und ob die Pegel eventuell invertiert sind [schau
Dir ne funktionierende rs232 Kommunikation andernorts an zum Vergleich,
versuche Ruhezustand (Mark, logisch 1) und Space (logisch 0) zu erkennen
um ein Gefühl dafür zu bekommen wie sowas aussehen muss]).
The SphereX schrieb:> Danke erst mal für den Hinweis, aber das Vertauschen von TX und RX hat> leider auch nichts gebracht.
nicht vertauschen! Die Pegel müssen invertiert werden - entweder
pfriemelst du was mit Invertern zusammen oder du nimmst einen USB-UART
Adapter bei dem man das einstellen kann wie z.B. den FT232
lg
Chris
ich habe gerade in den Dateien zum Bootloader was geändert:
in der FASTLOAD.H sind die Makros definiert, die für die Pegel
veranwtortlich sind. Ich habe das bei Onewire dann so geändert, dass es
jetzt auch ohne Invertierung der Pegel direkt an einem USB-UART Adpater
funktioniert.
Der letzte Abschnitt mit den Makros muss wie folgt aussehen (einfach
ersetzen):
Anschließend muss natürlich der Bootloader neu assembliert werden
Na das war jetzt aber fast schon Gedankenübertragung, denn meine nächste
Frage hier wäre gewesen, ob man nicht einfach den Bootloader selbst so
anpassen könnte, daß er auch nicht-invertierte Pegel akzeptiert.
Da warst Du wohl schneller ;-) ....
Ich werde Deine Modifikation heute gleich noch ausprobieren.
Grüße,
The SphereX
So, habe gerade den Bootloader mit den veränderten Macros neu kompiliert
und einen weiteren Verbindungsversuch gestartet, leider wieder ohne
Erfolg. Keine Ahnung, was da schief läuft!?
Der Bootloader + 1-Wire Hardware war eigentlich als schnell zu
realisierende und vor allem kostengünstige Alternative zu einem "High
Voltage Serial Programmer" gedacht und auch nur für den Fall, daß ich
die Software auf einem 8-Pin Tiny mit Reset als I/O doch mal
nachträglich verändern möchte. Dabei hatte ich natürlich nicht mit
derartigen Komplikationen gerechnet. Und ich bin nach wie vor auch der
Ansicht, daß sich die Fehlersuche hier sehr schwierig gestaltet.
Dann werde ich mir wohl doch lieber einen "Fusebit Doctor" basteln, der
mir dann ebenfalls eine Neuprogrammierung erlaubt.
http://mdiy.pl/attiny-fusebit-hvsp-doctor/?lang=en
Es sei denn, ich bekomme hier doch noch DEN entscheidenden Hinweis zur
Problemlösung mit dem Bootloader.
Grüße,
The SphereX
Ich hatte mit dem UpdateLoader leider auch immer wieder
Verbindungsprobleme mit den geänderten Dateien.
Mit Peters FBOOT.exe geht es jedoch problemlos. Ist halt leider ohne
GUI, aber eine kleine Batch-Datei dazu ist ja auch kein Problem:
Die beiden Dateien und die zu flashende HEX-Datei in einen Ordner
kopieren. Die hex-Datei in program.hex umbenennen (oder alternativ in
der fboot.bat den Dateinamen anpassen). In der Batch ist COM2
eingestellt, auch das ggf. anpassen. Passwort ist das standardmäßig
eingestellte (Peda).
1
FBOOT.exe /C2 /Pprogram.hex /Vprogram.hex /iPeda
So funktionierts bei mir problemlos mit Atmega88 und Attiny13.
lg
Chris
Ok, dann experimentieren wir halt doch noch ein bißchen herum.
Normalerweise gebe ich in solchen Fällen ja eigentlich auch nicht so
schnell auf ;-).
In dem Sinne, nach Eingabe von
FBOOT.exe /C3 /PTest.hex /VTest.hex /iPeda
erscheint Folgendes:
---------------------------------------
******* Push Reset Botton *******
COM 3 at 57600 Baud: -
---------------------------------------
Daraufhin verbinde ich kurz den Reset-Pin des ATTiny45 mit GND, aber es
tut sich nichts. FBOOT wartet und wartet .... Irgendwo ist da der Wurm
drin. Vielleicht fällt Dir an meiner Konfiguration ja noch was auf.
1. Fastboot
-----------
> Bootload.asm
--> .include "tn45def.inc"
--> .equ STX_PORT = PORTB
--> .equ STX = PB2
--> .equ SRX_PORT = PORTB
--> .equ SRX = PB2
> Fastload.h
--> .equ XTAL = 8000000
--> .equ BootDelay = XTAL / 3
--> Onewire Macro nach Deinen Vorgaben angepaßt
2. Kompilieren
--------------
> avrasm2 -fI BOOTLOAD.ASM
--> ohne Fehler
3. Fuses
--------
> 8 MHz internal oscillator> Div8 disabled> Selfprogramming enabled
4. Win7 Gerätemanager: Prolific USB-to-Serial Comm Port (COM3)
--------------------------------------------------------------
> Siehe Screenshots!
5. Schaltung
------------
> nach Deinem Hinweis:
--> ROT (5 V) --> VCC
USB2TTL --> SCHWARZ --> GND
--> WEISS RX (0 V) --> PB2
--> GRÜN TX (3,3 V) --> 10 kOhm --> PB2
Grüße,
The SphereX
Hi,
ich habe leider keinen Attiny45 da, sonst könnte ich dein Hex-File
testen, um dort Fehler auszuschließen.
Attiny25 hätte ich allerdings da.
Ansonsten: Hast du einen Atmega8, Atmega88, Atmega328, Attiny13 oder
Attiny44?
Dann kann ich dir ein funktionierendes HEX-File schicken zum Testen.
An der sonstigen Konfiguration passt ja eigentlich alles, im
Geräte-Manager muss man eigentlich auch nichts ändern.
lg
Chris
Na das Angebot nehme ich doch gerne an. So nähern wir uns meinem Problem
sicherlich am besten. Ich würde mich dann alternativ für den ATTiny13
entscheiden. Davon habe ich noch ein paar vorrätig und könnte
entsprechend Deinen Bootloader damit testen :-).
Grüße,
The SphereX
Danke Dir schon mal! Ich bräuchte dann vielleicht noch die Taktung.
Werkseinstellung mit 1,2 MHz (9,6 MHz, CKDIV8) oder ohne Teiler 9,6 MHz?
Grüße,
The SphereX
So, weiter geht's im Programm .....
Ich habe also Deine Bootloader-Version auf einen ATTiny13 geschrieben,
alles wieder verkabelt und dann zunächst weiter mit FBoot herumprobiert.
FBOOT.exe /C3 /B9600 /PTest.hex /VTest.hex /iPeda
Bei der Baudrate habe ich mehrere Werte ausprobiert (zwischen 1200 und
11520). Bei den meisten Versuchen hat es dann wenige Sekunden bis
mehrere Minuten (!) gedauert, bis dann folgende Meldung erschien:
----------------------------------------
******* Push Reset Botton *******
COM 3 at 9600 Baud: Connected (One wire)
Bootloader VFFFFFFFF.FF
Error, wrong device informations
----------------------------------------
Ein einziges Mal dachte ich dann schon, daß es funktioniert hat:
-----------------------------------------------------------
******* Push Reset Botton *******
COM 3 at 9600 Baud: Connected
Bootloader V2.1
Target: 1E9007 C:\FBOOT.DEF
Buffer: 32 Byte
Size available: 542 Byte
Program test.hex: 00000 - 00020 failed!
Program-Error
-----------------------------------------------------------
Aber zu früh gefreut. Hier scheint zwar der Bootloader erkannt worden zu
sein, allerdings jedoch nicht die One-Wire-Connection, und genau so
wenig der ATTiny13, denn der müßte ja eigentlich bei "Target:" hinter
der Hex-Zahl stehen.
Naja, und mit dem UpdateLoader hat's natürlich auch weiterhin nicht
geklappt.
Positiv ist aber immerhin, daß ich mit FBoot jetzt zumindest schon mal
Anzeichen von "Aktivität", um's mal vorsichtig auszudrücken, feststellen
konnte. Aber was fange ich jetzt mit dieser Erkenntnis an?
Grüße,
The SphereX
Aus lauter Verzweiflung habe ich gerade einfach noch mal den von Dir
verwendeten 10 kOhm Widerstand durch die in der ursprünglichen Schaltung
vorgesehenen 4700 kOhm ersetzt.
UND SIEHE DA: ES FUNKTIONIERT :-) !!!
Und zwar absolut problemlos sowohl mit FBoot, als auch mit dem
UpdateLoader (hier allerdings nur bis max. 57600 Baud). Mit meinem
ATTiny45 klappt's jetzt auch wunderbar. Es lag in meiner Schaltung also
ganz offensichtlich tatsächlich nur am zu hohen Widerstand und
softwareseitig natürlich an den invertierten Pegeln, die im
ursprünglichen Fastboot-Code enthalten sind. Da wäre ich ohne Dich
sicherlich nie darauf gekommen und würde entsprechend auch mit den 4700
kOhm jetzt noch ziemlich ratlos dasitzen.
Also nochmals DANKE :-) !!!
Grüße,
The SphereX
Schön zu hören dass es jetzt funktioniert ;)
Ich hatte allerdings mit den 10kOhm zum Glück keine Probleme. Mal schaun
obs mit 4k7 dann auch mit Update Loader klappt bei mir
