ATtiny13 und STK200 über PonyProg2000 flashen

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo zusammen,

es ist zum verzweifeln. Habe das selbe Problem wie unter
" Attiny13 kein Upload mehr möglich ".

Zusätzlich ist mir aufgefallen das schon das Initialisieren mit Lpmikros 
und dem Updateprogramm LpmikroISP nicht funktioniert, obwohl die 
Statusbalken sich füllen und ok angezeigt wird.
Das dies nicht hingehauen hat erkenne ich immer daran,
das ich vom Reiter Initialisieren nach ziehen der RESET-Brücke,
zum Reiter Interface wechsle.
Dort zeigen bei Erfolgreichem Initialisieren die Analogkanäle ADC 2,3 
andere Werte als 0 Volt an.

Nun die ATtinys sind nicht defekt. Das weiß ich daher, weil ich den 
orginal IC (10PU) wieder nach länger Zeit eingesetzt habe und er ein 
paar Mal wieder seine Aufgabe erledigt hat. Auch ganz neue ICs (20PU) 
lassen sich nicht Intitialisieren.

Nun möchte ich ganz vom Franzis Lernpaket Mikrocontroller weg,
sowohl von der Hardware als auch von der Software.
Da ich ein geliehenes ATMEL STK200 board besitze,
dachte ich mir dieses zum flashen des ATtiny13 zu nutzen.
Mittels seriellenprogrammieradapters und PonyProg2000 Version 2.07a Beta
läßt sich dieser auch anstandslos flashen (Write successful).
Aber das Programm (Blink1.hex vom Franzis LP) das an PortB3 eine LED 
blinken lassen soll tut seine Arbeit nicht. Die LED ist ständig an.

Das flashen eines AT90S2313 funktioniert einwandfrei.

Wer hat Lust mir genaustens zu beschreiben wie er seine ATtiny13 mit dem
STK200 über PonyProg2000 seriell (COM-Schnittstelle) flashed bzw. eine 
andere einfache Hardware in verbindung mit PonyProg2000 nutzt ?

Das Internet ist voll damit, aber ich sehe den Wald vor lauter Bäumen 
nicht mehr und möchte nun ein einfaches System womit andere auch gute 
Erfahrungen gemacht haben.

Bis dann

Bernd_Stein

[Hubert G. (hubertg)]

Das flashen eines Tiny13 ist nicht anders als einen 90S2313. Kenne 
allerdings das STK200 nicht.
Mit PonyProg verwende ich die angehängte Schaltung.

[spess53 (Gast)]

Hi

>Aber das Programm (Blink1.hex vom Franzis LP) das an PortB3 eine LED
>blinken lassen soll tut seine Arbeit nicht. Die LED ist ständig an.

Das STK200 kennt am 8-pol. Sockel kein PB3. Lediglich PB0..PB2. PB3 und 
PB4 sind Quartzanschlüsse.

MfG Spess

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Das STK200 kennt am 8-pol. Sockel kein PB3. Lediglich PB0..PB2. PB3 und
PB4 sind Quartzanschlüsse.

MfG Spess


Danke,
das erklärt natürlich einiges. Ich wundere mich immer wieder wie einige 
solche Dinge herausbekommen.
Im Handbuch zum STK200 in Section 9.1.1
Using 8-Pin Devices with LEDs ist das nicht so zu erkennen.
Die hätten ja mal den Schaltplan auch da hineinpacken können.

Ein Schaltplan sagt ja manchmal auch mehr als tausend Worte.

Der ist Schaltplan ist bestimmt auf der CD, die ich leider nicht 
besitze.

Gruß

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

>Das STK200 kennt am 8-pol. Sockel kein PB3. Lediglich PB0..PB2. PB3 und
>PB4 sind Quartzanschlüsse.

MfG Spess


Danke,
das erklärt natürlich einiges. Ich wundere mich immer wieder wie einige 
solche Dinge herausbekommen.
Im Handbuch zum STK200 in Section 9.1.1
Using 8-Pin Devices with LEDs ist das nicht so zu erkennen.
Die hätten ja mal den Schaltplan auch da hineinpacken können.

Ein Schaltplan sagt ja manchmal auch mehr als tausend Worte.

Der ist Schaltplan ist bestimmt auf der CD, die ich leider nicht 
besitze.

Gruß

Bernd_Stein

[Hubert G. (hubertg)]

Den Schaltplan habe ich mir mal wo runtergezogen, hoffe er passt.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hubert G. schrieb:
> Das flashen eines Tiny13 ist nicht anders als einen 90S2313. Kenne
> allerdings das STK200 nicht.
> Mit PonyProg verwende ich die angehängte Schaltung.

Danke,
ich habe schon so eine ähnliche Schaltung vom Pollin AVR Board 
übernommen.
Das schöne an der Franzisplatine bzw. der Software ist ja das man nicht 
noch extra eine Spannungsversorgung braucht und das man sich über einen 
Adaptersockel schnell eine Verbindung zu einer Schaltung machen kann 
ohne die IC herausnehmen zu müssen.

Dachte mit dem ATMEL STK200 Board wäre ich flexibel, jetzt muß ich 
leider feststellen das ich schon wieder eine Platine machen muß, die am 
besten meinen Adapter für die Franzisplatine nutzen kann.
Werde dafür den von Dir vorgeschlagenen seriellen ISP nutzen, da ich 
irgendwie im Hinterkopf habe das der Kondensator nützlich gegen 
Störungen ist und die zusätzlichen 1k Ohm Widerstände in Reihe zu den 
4k7 Ohm Widerständen dazu dienen um auch bei 3,3 Volt Spannungsversorung 
flashen zu können.

Gruß

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Danke Hubert G.,

für den Schaltplan.
Der müsste genau zu dem Board passen. Das Handbuch ist nämlich
vom November 1998.
Allerdings vermisse ich den Jumper Clock Sel (Int und Ext). Wundere mich 
das der 3polig ist. Meine das für den Internen Clock XTAL unbeschaltet 
bleiben kann.

Gruß

Bernd_Stein

[spess53 (Gast)]

Hi

>Dachte mit dem ATMEL STK200 Board wäre ich flexibel...

Dem war beim Erscheinen des STK200 auch so. Die im Handbuch angegebenen 
Typen wirst du heute kaum noch bekommen. Die heutigen AVRs haben eine 
ganze Reihe Features, die damals noch nicht abzusehen waren. Ich habe 
hier auch noch ein STK200 das ich ab und zu auch benutze.
Allerdings solltest du auch etwas flexibel sein. Biege z.B. die beiden 
Port-Pins des ATTiny13 nach aussen. Löte ein paar Drähte an und steck 
die an die entsprechenden Stellen von einem anderen Sockel. Und schon 
hast du PB3 und PB4.

MfG Spess

[spess53 (Gast)]

Hi

>Kann problemlos alle ATtiny13 wieder im STK200 flashen indem ich ganz
>normal diese in den 8 Pol Sockel stecke

Der Vorschlag hatte nichts mit dem Flashen zu tun. Die Pins dafür sind 
ja am Sockel vorhanden.

MfG Spess

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Jetzt holt mich das Problem von früher wieder ein.

Hatte damals vermutlich die Lockbits 1&2 verändert ( so steht es 
zumindest auf dem Aufkleber ).

Nun sollte es ja möglich sein, mit der seriellen Hochspannungsmethode ( 
HVSP ) doch wieder Zugriff auf den AtTiny13 zu bekommen.

Dazu habe ich hier ein Programm heruntergeladen, aber es gibt das 
Probleme im AS7 dieses zu compilieren.

http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html

Kann hier jemand der sich mit C auskennt, das compilierte Programm, also 
die Hex-Datei hoch laden ?


Bernd_Stein

[Stefan F. (Gast)]

Benutze die richtigen Tools für das Programm. Makefile Projekte 
compiliert man auf der Kommandozeile mit dem Befehl "make".

Wenn du das AVR Studio installiert hast, müsstest du im Startmenü extra 
einen Eintrag für eine "Atmel Command Shell" oder so ähnlich haben.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hallo Stefanus,

möchte nur das Hexfile haben, um damit den AtMega8 zu flashen. Du weißt 
von C habe ich keine Ahnung und deshalb wäre das Schönste für mich, 
jemand macht dieses Hexfile. Deshalb hab ich mal die Dateien angehangen 
die im Zip-Ordner waren.


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> möchte nur das Hexfile haben, um damit den AtMega8 zu flashen

Genau das erstellt Dir der make Befehl. Bitteschön.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Bernd S. schrieb:
>> möchte nur das Hexfile haben, um damit den AtMega8 zu flashen
>
> Genau das erstellt Dir der make Befehl. Bitteschön.
>
Danke, damit hast du mir viel Zeit und Nerven gespart. So stelle ich mir 
vernüpftiges Miteinander vor. Nicht was sonst so in den Threads 
passiert.


Bernd_Stein

[S. Landolt (Gast)]

>  seriellen Hochspannungsmethode ( HVSP )

Nur um Lock-bits zu löschen? Ein Chip-erase im normalen seriellen Modus 
sollte doch reichen?

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

S. Landolt schrieb:
>>  seriellen Hochspannungsmethode ( HVSP )
>
> Nur um Lock-bits zu löschen? Ein Chip-erase im normalen seriellen Modus
> sollte doch reichen?
>
Ich kann auf den IC nicht zugreifen, ( weder mit ATMEL-ICE noch 
AVRISP-MKII mit niedrigstem Clock ) hoffe deshalb das hier HVSP hilft.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

So, jetzt das Ganze für einen AtMega88PA.

Wollte diesen mit einem 20MHz Quarz betreiben und Debug-Wire benutzen 
und habe hierzu das DWEN-Häkchen weggemacht ( vermutlich Unprogrammed ).

Warum dies schon angehakt war, weiß ich nicht ( vermute Haken = 
angewählt ).

Schlimmer ist, das ich :

" Ext. Full-swing Crystal; Start-up time PWRDWN/Reset: 16K CK/14CK +65ms 
EXTFSXTAL_16KCK_14CK_64MS "

ausgewählt habe.

Vermutlich ist dies ( EXTFSXTAL_16KCK_14CK_64MS ) die Kurzcodierung für 
den ganzen Kladeraratsch.

Habe schon kleinere Quarze und verschiedene Kerkos benutzt, aber ohne 
Erfolg.

Schlußendlich den universellen Transistortester, der hier im Forum 
entwickelt wurde ( GM328A ), mit 2MHz an Pin9 ( XTAL1 = IN, CH2 blau ) 
angeschlossen ( XTAL2 = Out, CH1 gleb ), aber auch damit kein Erfolg.

Mal sehen ob hier HVSP was bringt.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Ach, könnte mir noch jemand die bei der Auslieferung eingestellten 
FUSE-Bits mitteilen. Habe nämlich keinen mehr, der sich noch im 
Auslieferungszustand befindet.

Bei der Datenbuchüberarbeitung hat sich wieder mal ein Fehler 
eingeschlichen, deshalb wäre es gut, wenn mir jemand den gefallen in 
dieser Form tun könnte.

FUSE-High-Byte = $XY

FUSE- Low_Byte = $XY

FUSES Extendet müsste = $F9 sein.


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Ach, könnte mir noch jemand die bei der Auslieferung eingestellten
> FUSE-Bits mitteilen.

Die stehen im Datenblatt. Kannst du auch dort nachsehen: 
http://www.engbedded.com/fusecalc/

[spess53 (Gast)]

Hi

>Ach, könnte mir noch jemand die bei der Auslieferung eingestellten
>FUSE-Bits mitteilen.

Bitte:

http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf

S.290ff

MfG Spess

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Die stehen im Datenblatt. Kannst du auch dort nachsehen:
> http://www.engbedded.com/fusecalc/
>
Danke, interessante Sache, habe sie mir aber erstmal nur kurz 
angeschaut.

spess53 schrieb:
> Bitte:
>
> 
http://ww1.microchip.com/downloads/en/DeviceDoc/ATmega48A-PA-88A-PA-168A-PA-328-P-DS-DS40002061A.pdf
>
> S.290ff
>
Danke, FUSE BITS war also das Stichwort, hatte immer nach shipped 
gesucht.
Hatte auch ein anderes DB ( DS4000 2011A ) mit nur 495 Seiten ;-),
aber da steht zum Glück das Gleiche drinn, deshalb nehme ich mal an, das 
das alles stimmt, was ich hier unten zum Auslieferungszustand schreibe.

AtMega88PA -> *Device Signature $1E 94 0B*

FUSE-Extended  $F9

FUSE-High-Byte $DF

FUSE- Low-Byte $62


Sind alle AtMega88PA davon betroffen oder was sagt mir rev K ?

Was muss ich denn jetzt einstellen, um diesen mit 20MHz zu betreiben ?

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Was muss ich denn jetzt einstellen, um diesen mit 20MHz zu betreiben ?
>
Tja, da werde ich wohl selber Experimentieren müssen, wenn das hier 
keiner weiß.

Mein AtTiny13, AtMega8L und AtMega88PA, konnte ich leider nicht mit der 
verlinkten Schaltung zum Leben erwecken.

Hatte erst einen AtMega168PA mit dem Hexfile geflashed, weil ich keinen 
AtMega8 und 88 mehr zur Verfügung habe, aber das funktionierte nicht.

In einer anderen Schaltung hatte ich glücklicherweise noch einen 
Atmega8, der dann wohl seinen Dienst verrichtete.

Die LED blinkt nur. 12V werden am Resetpin angelegt und auch der Rest 
sieht mit dem OLS ( Open Workbench Logic Sniffer ) so aus,
als ob es so sein müsste ;-)

http://homepage.hispeed.ch/peterfleury/avr-hvsp-fuse-restore.html

Vielleicht werde ich mal neue AtTiny2313 und AtTiny26 damit 
ausprobieren, da müsste die LED ja mit Dauerlicht zeigen das das HVSP 
funktionierte.


Bernd_Stein

[spess53 (Gast)]

Hi

>AtMega88PA -> *Device Signature $1E 94 0B*

Wo hast du denn diese Signatur her?

Beim ATmega88PA ist diese 0x1E 0x93 0x0F. Die 0x1E 0x94 0x0B gehört zum
ATmega168PA.

MfG Spess

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

spess53 schrieb:
> Hi
>
>>AtMega88PA -> *Device Signature $1E 94 0B*
>
> Wo hast du denn diese Signatur her?
>
> Beim ATmega88PA ist diese 0x1E 0x93 0x0F. Die 0x1E 0x94 0x0B gehört zum
> ATmega168PA.
>
> MfG Spess
>
Mist, immer diese Flüchtigkeitsfehler.
Bestelle jetzt erstmal ein paar AtMega88PA, das ist einfacher ;-).

Im Screenshot kann man sehen, was ich eingestellt hatte und das 
herrliche Programm zeigt einem dann alles im Detail an.

http://www.engbedded.com/fusecalc/


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Hiernoch was das Hex-File macht.

HVSP-Phase zeigt den Ausschnitt, wo die 12V an /Reset angelegt werden, 
was etwas verzögert zu Vcc passiert, aber gleichzeitig abschaltet. 
Danach bleibt der "normale" /Reset dauerhaft anstehen und die Vcc sind 
weggeschaltet.

Der zu Resettende Baustein erhält also seine Versorungsspannung über PC4 
( Pin 27 ) vom FUSE-Restore µC ( AtMega8 ).

Mich wundert ein wenig, das SCK die ganze Zeit weitertaktet, obwohl die 
LED-Anzeige fertig ist.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Tja - wie meistens üblich, wenn es komplizierter wird, braucht man hier 
nicht auf Hilfe hoffen.

Dabei brauchte man eigentlich nur zu Wissen das man

*den AtMega8(L) & AtMega88 kann man gar nicht HV-Seriell programmieren 
kann !!!*

Hier wurde übrigens damals das Projekt vorgestellt :

Beitrag "[AVR (AVR-GCC)] Einfach aufzubauenden ATtiny Fuse Resetter (HVSP)"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Mit dieser Einstellung und 22pF gehts. Sind aber noch andere Änderungen 
gegenüber dem Auslieferungszustand vorgenommen, also vorher verlinktes 
Programm benutzen um zu sehen was anders ist.

FUSE-Highbyte $D7
FUSE- Lowbyte $DE

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Immer diese Probleme beim Flashen.

Brauchte einen AVR-8 mit möglichst vielen I/O-Lines.
Bin dabei mit der Suche nach TQFP100 auf den AtMega6490P gestossen.
Der AtMega640 wäre besser gewesen, aber die Suche bei Microchip ist 
einfach scheiße.

Also Adapterplatine vom Chinesen (TQFP 32-100), µC und 0603 
Stützkondensatoren verlötet, danach die 2,54mm Stiftleiste an der Seite 
angelötet, wo die ISP-Pins rausgeführt sind.

Super, der µC läßt sich ansprechen und flups die Signatur $1E960C und 
weiteres ausgelesen ( Extended $FF, High $99, Low $62 ).

Danach JTAG ausprobiert - klappt.

Irgendwann lies sich dann der µC über beide Schnittstellen nicht mehr 
ansprechen. Also neuen µC und alles wieder paletti. EESAVE aktiviert.

Später bemerkt, das die Portpins F4 bis F7 schon bei einer geringen 
Belastung ( Eingang ULN2803A ) mit der Spannung einbrechen ( Von 4,0V 
auf 1,0V ). Um diese Pins zu testen, hatte ich vorher wieder auf ISP 
gewechselt.

Die erste Annahme war, das der ULN defekt sei. Diesen getauscht, danach 
das Gleiche. Deshalb gedacht, dass wieder die µC Pins nicht richtig 
verlötet waren, so wie ich es vorher an PortB5-7 hatte, aber das war 
diesmal nicht der Fehler. Nach langer Recherche festgestellt, das dies 
daran liegen muss, das vorher JTAG eingestellt war, also OCDEN wieder 
raus.

Danach wieder über beide Schnittstellen kein Zugriff auf den µC.
Schon bei der ersten Platine bemerkt, das diese China Verbindungskabel, 
( Diese Breadbord Dinger ), welche ja bekanntlich mehr Plastik und Eisen 
enthalten als Kupfer ( wenn überhaupt Kupfer ), keinen soliden 
Steckkontakt aufwiesen. Vermute deshalb, das es während der Übertragung 
zu einem Bitkippen kommt und ich somit irgendwie den µC verfuse.

Oder habe ich einfach nur eine schlechte Charge des AtMega6490P 
erwischt?

Langsam wirds teuer.


Bernd_Stein

[c-hater (Gast)]

Bernd S. schrieb:

> Immer diese Probleme beim Flashen.

Meine Beobachtung: nur absolute Anfänger und Unbelehrbare haben damit 
Probleme. Bei Anfängern kann man das akzeptieren, man war ja schließlich 
selber mal einer...

> Irgendwann lies sich dann der µC über beide Schnittstellen nicht mehr
> ansprechen.

Es war also irgendwas SCHEISSE von all dem, was du in der Zwischenzeit 
getan, uns aber nicht verraten hast...

So einfach ist das. Jedem, der auch nur grundlegend die Wirksamkeit der 
Regeln der Logik zuzugeben bereit ist, MUSS das klar sein.

Der Rest sind halt die Unbelehrbaren. Denen ist nicht zu helfen. Oder 
allenfalls in der geschlossenen Psychiatrie...

[Stefan F. (Gast)]

c-hater schrieb:
> nur absolute Anfänger und Unbelehrbare haben damit Probleme
> SCHEISSE Psychiatrie

Ist sonst alles in Ordnung bei Dir?

[c-hater (Gast)]

Stefanus F. schrieb:

> c-hater schrieb:
>> nur absolute Anfänger und Unbelehrbare haben damit Probleme
>> SCHEISSE Psychiatrie
>
> Ist sonst alles in Ordnung bei Dir?

Und bei dir? Du fälschst Zitate in einem Ausmass, dass es nicht mehr mit 
einem Versehen erklärbar ist. Das ist für jeden leicht erkennbar 
vollkommen sinnentstellend.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

@c-hater
Bist du umoperiert und die Hormone lassen dich durchdrehen oder haben 
sie  dich zu früh aus der Psychatrie rausgelassen?


Bernd_Stein

[Logik-Anneliesator (Gast)]

Bernd S. schrieb:
> @c-hater
> Bist du umoperiert und die Hormone lassen dich durchdrehen oder haben
> sie  dich zu früh aus der Psychatrie rausgelassen?

Ach was, der ist bloß ver-fused und leidet unter dem nun zu hohen Takt.
Ab und zu kommt er beim Polling von Beiträgen über die Grenzen seines 
kleinen Arrays und läuft über. Das bringt ihn dazu, über seinen UART 
unzusammenhängende Schimpftiraden mit enormer Baudrate auszugeben.
Leider wird sein Sendepuffer dadurch kaum leerer.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Habe jetzt erstmal vernünftige vergoldete Crimpbuchsen von Amphenol ( 
48045-000LF ) für die 2,54mm ( 0,64mm x 0,64mm ) Stiftleisten bestellt.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Nach langer Recherche festgestellt, das dies
> daran liegen muss, das vorher JTAG eingestellt war, also OCDEN wieder
> raus.
>
Vielleicht lag es auch daran dass ich mit dem On-chip debug system 
rumgespielt habe. Jetzt funktioniert alles erstmal und ich habe stark 
drauf geachtet, das die Chinasteckverbindungen guten Kontakt haben. Dazu 
habe ich die Isolierhülse abgemacht und stattdessen Schrumpfschlauch 
verwendent, denn auf dem letzten Millimeter merkt man deutlich, dass 
jetzt erst ein "einrasten" erfolgt. Statt OCDEN habe ich JTAGEN 
rausgenommen, damit die Bits 4-7 von PortF vernünftig funktionieren.

Eine Adapterplatine nur mit dem µc zu verlöten, hat mich 2 Std. 
gekostet.
Ich verwendete in Brennspiritus aufgelöstes Kolophonium, das ich hätte 
drauf lassen können, aber nicht wollte. Hätte nicht gedacht, das dieses 
ständige reinigigen soviel Zeit in Anspruch nimmt. Außerdem lies sich 
der µC damit nicht so schön verlöten, wie es in dem nachfolgenden 
verlinkten Thread gezeigt wird. Aber was will man machen, wenn die 
Chinaprodukte so lange brauchen bis sie hier ankommen.

Hier mal ein paar Fotos, wo ich den alten µC abgelötet habe und leider 
auch die 0603 Kerkos flöten gegangen sind :

Beitrag "TQFP 100 entlöten"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Habe jetzt erstmal vernünftige vergoldete Crimpbuchsen von Amphenol (
> 48045-000LF ) für die 2,54mm ( 0,64mm x 0,64mm ) Stiftleisten bestellt.
>
Habe ja lange nach so etwas gesucht und muss sagen, die sind wirklich 
klasse.
Da die Reel-Ausführung günstiger war, habe ich diese genommen. Wer nicht 
jede einzelne Buchse von der Drahtführung abmachen möchte, sollte die 
Loose-Ausführung nehmen ( 48238-000LF ) oder halt die anderen passenden 
Ausführungen ( siehe PDF-Anhang im anderen Posting ).


Hatte mit meiner Suche bei Reichelt begonnen und auch versucht 
telefonisch hilfe zu bekommen, aber die Ratschläge für deren Sortiment 
passen halt nicht für diese Stiftleisten.

Ich hatte mich dann für diese entschieden :

JST EH CKS, JST PH CKB, JST XH CKB.

Der schlechteste ist JST XH CKB. Total lose und stellt sich immer 
schief.

Die Amphenol-Crimpbuchsen habe ich mit der Reichelt-Zange für 
PSK-Kontakte gecrimpt ( CRIMPZANGE PSK ) und diese Zange immer ein wenig 
bearbeitet, um bessere Ergebnisse zu bekommen, aber alles ohne Erfolg.
Mir reicht jedoch das Ergebnis der Crimpung mit Flachbandkabel ( AWG28 
-> 0,09qmm ) auch wenn die Crimpbuchsen sich verbiegen.

Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Tja, eins bleibt bei dem Fehlerbild wenigstens gleich - als Signature 
Bytes werden immer $FF FF FF ausgelesen ;-)

Versuche mich jetzt mal genau zu erinnern was ich vor dem Ausfall 
gemacht habe.

Es ging also darum, das sich der Systemtakt nicht verändern lies. Auf 
den Simulator war wieder kein Verlass und Stefanus F. gab mir den Rat 
per Emulator ( ATMEL ICE ) nach dem Fehler zu suchen. Blöderweise ist 
der Output, den ich untersuche, genau auf dem Port ( PORTF ) wo auch 
JTAG angeschlossen wird.

Also JTAG angeschlossen und trotzdem PortF0 ( Pin 97 ) ans Oszi 
gehangen.
Kurz gewundert, dass wieder kein Zugriff hierüber auf den µC besteht, 
dann war aber schnell klar, dass noch JTAGEN gesetzt werden muss. Dies 
deaktiviere ich immer, damit PortF vernünftig arbeiten kann.

Diesmal hatte ich beide Schnittstellen aufgesteckt gelassen ( ISP & JTAG 
) und ein Zugriff über ISP war auch nicht möglich. Also JTAG komplett 
abgezogen und JTAGEN über ISP aktiviert.

Meine Programmierkabel ( 10polig ) sind relativ lang. Vom ATMEL ICE zum 
µC sind es ca. 400mm. Aber das kann es doch nicht wirklich sein, denn es 
ging jetzt ja ziemlich lange gut und das Programm flashen machte ja nie 
Probleme ?


Bernd_Stein

[Stefan F. (Gast)]

Bernd S. schrieb:
> Vom ATMEL ICE zum
> µC sind es ca. 400mm. Aber das kann es doch nicht wirklich sein

Ich verwende nur sehr kurze Kabel (15-20cm). Irgendwo habe ich mal 
gelesen, das bis 30cm kein Problem seien. Deine 40cm machen mich daher 
schon stutzig, ich würde mal mit einem kürzeren versuchen.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Deine 40cm machen mich daher
> schon stutzig, ich würde mal mit einem kürzeren versuchen.
>
Das scheint mir eh nicht das Problem zu sein.
Habe wieder eine kleine Veränderung vorgenommen. Hab diese 
China-Dupont-Strippen, welche vorher über die Pins 10&11 die 
Adapterplatine versorgt haben rausgeschmissen und versorge jetzt mit den 
Amphenol-Crimpbuchsen und vernünftiger 0,14qmm Leitung die 
Adapterplatine. Bei 0,14qmm verbiegen sich die Crimpbuchsen noch mehr 
als bei der Flachbandleitung mit 0,09qmm, aber ich habe eben einen 
vernüftigen Kontakt.

Diese neue Adapterplatine funktioniert jetzt erstmal wieder, aber es 
gibt ein neues Problem :

Beitrag "Debuging per ATMEL ICE verstehen"


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

*Es ist zum Wahnsinnig werden.*

Wieder mal kein Zugriff auf den AtMega6490P. Jetzt mit dem AVRISP mkII.

Weil ich diesmal ständig High-Pegel auf PF0 hatte, nahm ich die 
Adapterplatine in die Hand, um zu gucken ob alles noch gut gesteckt ist.

Jetzt gibt es ein etwas anderes Problem, denn es geht nicht um die 
Signaturebytes, sondern irgendwas, was beim Empfangen $00 erwartet,
aber $C0 bekommt.

Meine Programmlaufanzeige ( PLA ) hat mich wieder mal auf zwei Sachen 
hingewiesen :

1. Sie blinkt langsamer, das bedeutet, das der Systemtakt also 
umgestellt sein muss.

2. Wenn ich das USB-Kabel vom AVRISP mkII abziehe geht sie aus und 
bleibt aus. Das wiederum bedeutet -> Kein Programmlauf.

Ich speise die Adapterplatine über die Pins 10&11 ein. Es scheinen die 
Versorgungspins 31&32, sowie 80&81 wohl auch noch extra eingespeist 
werden zu müssen, denn durch das Abziehen des USB-Kabels, schein ich ja 
irgendwie die Masse an Pin 32 zu unterbrechen.

Jetzt kann ich erstmal etwas basteln, was alle drei 
Versorgungspinpärchen versorgt und auch noch die Möglichkeit schafft den 
AVRISP mkII, sowie den ATMEL ICE, durch Aufstecken mit dieser Spannung 
zu versorgen.

Die oberste Adapterplatine ist dafür da, dass ich noch die Pinnummern 
lesen kann.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

So, speise jetzt alle drei Versorgungspärchen ein und kann auch noch ISP 
& JTAG adaptieren. War natürlich erstmal depremiert, dass ich hiernach 
immer noch das gleiche Fehlerbild hatte. Dann kam mir ein Geistesblitz, 
denn wenn die PLA-LED ja jetzt langsamer blinkt, ist wahrscheinlich die 
ISP-Freqeunz zu hoch ( darf ja nur 1/4 des Systemtaktes sein ).

Tatsache - mit maximal 64kHz ISP-Clock, kann ich wieder auf den µC 
zugreifen.

Der ganze Spuk hat jetzt eine Ende.
War sehr erstaunt, das die PLA-LED erlosch, wenn ich das USB-Kabel abzog 
aber nicht, wenn ich den 10-Poligen ISP Stecker zog. Es ist einfach ein 
Power-On-Reset, Spannungsversorgung eine zeitlang abziehen, bei der 
Adapterplatine durchzuführen, wenn das USB-Kabel abgezogen ist.

Danach blinkt auch wieder die PLA-LED. Ein Rätsel bleibt es für mich 
dennoch.

Bin jetzt wieder an dem Punkt, wo ich gucken kann, was mein PF0 Pin 
macht ;-)


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Bin jetzt wieder an dem Punkt, wo ich gucken kann, was mein PF0 Pin
> macht ;-)
>
Irgendwie kann das doch alles gar nicht sein. Ist ja wie verhext.
Selbst bei den einfachsten Dingen spinnt der Simulator. Ich weiß auf ihn 
ist kein Verlass, aber die einfachsten Sachen stimmen schon nicht. Das 
ist doch nicht normal.

Es soll einfach ein sehr schnelles Lauflicht erzeugt werden, was für den 
Betrachter so aussieht als ob alle LEDs gleichzeitig an sind.

Ich schaue mir nur PORTF0 ( Pin 97 ) mit dem Oszi an um zu sehen wie der 
ULN2803A schaltet und mit welcher Frequenz das Ganze arbeitet.

Aber PF0 ist ständig Low und ich finde die Ursache nicht. JTAGEN habe 
ich rausgenommen.

Das ich mich auf die serielle Schnittstelle ( UART ) wegen dem ungenauen 
Takt des internen RC-Oszillator nicht verlassen kann ist mir bewusst. 
Hoffe jedoch trotzdem das es bei 1200 Baud hinhaut, denn das ASCII 'F' 
bekomme ich immer korrekt angezeigt.

 ser  a                     ;Alle Ports (A-J) als Ausgaenge..
 out  DDRA,a                ;..mit dem Anfangszustand..
 out  DDRB,a                ;..Low..
 out  DDRC,a                ;..
 out  DDRD,a                ;..
 out  DDRE,a                ;..
 out  DDRF,a                ;..
 sbi  DDRG,PG0              ;Nur PortG0 als Ausgang
 sts  DDRH,a                ;..
 sts  DDRJ,a                ;..konfigurieren

_led_41_48:
 rol  a
 out  PORTF,a               ;Ein-Zustand einen weiterschalten
 

 rcall _warte_udre          ; T E S T ##########################################
 lds  b,PORTF               ;
 sts  UDR0,b                ;
 rcall _warte_udre          ;
 ldi  b,'F'                 ;
 sts  UDR0,b                ;
 rcall _warte_udre          ; T E S T ##########################################


 brne _led_41_48            ;8-Bits durch? NEIN -> Naechste LED von diesem Port
;
;Auf das Freiwerden des USART-Datenregisters warten
;
_warte_udre:                 ;TESTZWECKE #######################################
 push a                      ;
_warte_udre1:                ;
 lds  a,UCSR0A               ;
 sbrs a,UDRE0                ;
 rjmp _warte_udre1           ;
 pop  a                      ; T E S T #########################################
 ret

Bernd_Stein

[Stefan F. (Gast)]

Ich habe Dir schon mal gesagt, dass du den Simulator vergessen kannst. 
Lass ihn doch einfach, du hast Hardware mit Debugger. Das ist viel 
besser.

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Stefanus F. schrieb:
> Ich habe Dir schon mal gesagt, dass du den Simulator vergessen kannst.
> Lass ihn doch einfach, du hast Hardware mit Debugger. Das ist viel
> besser.
>
Das Problem ist doch, das ich Hardware-Debuging nur mittels JTAG machen 
kann und diese Schnittstelle blockiert PortF 4-7 was ich schon mal 
geschrieben habe. Gut PortF0 ist davon nicht betroffen, aber ...

Kein Aber, jetzt fällt mir erst auf, dass ich bei dieser Adapterplatine 
ja wunderbar an PortF 0,1,2,3 drankomme. Also kann ich doch wieder mit 
dem ATMEL ICE und der JTAG-Schnittstelle im Einzelschritt arbeiten, 
falls es notwendig wird, denn ...

Ah - jetzt blitzt PF3( Pin 94 ) auf. Das sind wahrscheinlich wieder 
schlechte Lötverbindungen an den µC-Pins. Glaube nicht das ich einzelne 
Portausgänge beschädigt habe.

Danke Stefanus F. jetzt kann es endlich weitergehen.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Bernd S. schrieb:
> Das sind wahrscheinlich wieder schlechte Lötverbindungen an den µC-Pins.
>
Genau so ist es.


Bernd_Stein

[Bernd S. (Firma: Anscheinend Corner-Cases ;-)) (bernd_stein)]

Falls es mal zu Problemen beim ISP-Zugriff auf einen mit DebugWIRE 
ausgestatteten AVR-uC kommt :

Beitrag "Kein ISP Zugriff auf den ATMega88PA"


Bernd_Stein