Schaltung mit ATtiny13A aus Solar-Leuchtturm weiter gedacht

[Stefan M. (beefjerky)]

Hallo zusammen,

ich hatte vor einiger Zeit Fragen zu einem Solar-Leuchtturm mit 
ATtiny13A eingestellt (Beitrag "Schaltung mit ATtiny13A aus Solar-Leuchtturm verstehen") und 
viele Antworten bekommen. Vielen Dank dafür, auch wenn ich letztlich 
nicht alles verstehen konnte!

Weil die Schaltung auf einem standardmäßigen ATtiny (und nicht z.B. auf 
einer kundenspezifischen MCU) basiert, habe ich mich gefragt, ob ich die 
MCU nicht auch auslesen oder sogar umprogrammieren könnte (z.B. auch 
einen Arduino draus machen). Also habe ich mir zum Experimentieren einen 
ISP-Programmer organisiert 
(https://www.diamex.de/dxshop/EXA-PROG-AVR-ISP-und-UPDI-STM32-NXP-ESP) 
und ein paar frabrikneue ATtiny13As im DIL8-Gehäuse dazu.

Die Kurzfassung:

Letzlich bin ich mit meinen Experimenten soweit gekommen, dass ich einen 
neuen ATtiny mit den Daten aus dem Originalen flashen konnte. Dann habe 
ich die Schaltung auf einem Breadboard nachgebaut (siehe Anhang), aber 
leider funktioniert sie nicht und ich brauche Hilfe den Fehler zu 
finden.

Die Langfasssung:

Ich habe Kupferlackdrähte an die 6 zum Programmieren benötigten Pins 
(Vcc, GND, RESET, MOSI, MISO, SCK) gelötet (siehe Anhang) und konnte mit

avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -n -v

tatsächlich folgende Informationen auslesen

avrdude.exe: Version 6.3-20190619
             Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
             Copyright (c) 2007-2014 Joerg Wunsch

             System wide configuration file is "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf"

             Using Port                    : COM7
             Using Programmer              : stk500
             AVR Part                      : ATtiny13
             Chip Erase delay              : 4000 us
             PAGEL                         : P00
             BS2                           : P00
             RESET disposition             : dedicated
             RETRY pulse                   : SCK
             serial program mode           : yes
             parallel program mode         : yes
             Timeout                       : 200
             StabDelay                     : 100
             CmdexeDelay                   : 25
             SyncLoops                     : 32
             ByteDelay                     : 0
             PollIndex                     : 3
             PollValue                     : 0x53
             Memory Detail                 :

                                      Block Poll               Page                       Polled
               Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
               ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
               eeprom        65     5     4    0 no         64    4      0  4000  4000 0xff 0xff
               flash         65     6    32    0 yes      1024   32     32  4500  4500 0xff 0xff
               signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00
               lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               calibration    0     0     0    0 no          2    0      0     0     0 0x00 0x00
               lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
               hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00

             Programmer Type : STK500V2
             Description     : Atmel STK500
             Programmer Model: STK500
             Hardware Version: 10
             Firmware Version Master : 2.10
             Topcard         : Unknown
             Vtarget         : 3.3 V
             SCK period      : 8.7 us
             Varef           : 3.3 V
             Oscillator      : 1.229 MHz

avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9007 (probably t13)
avrdude.exe: safemode: lfuse reads as 79
avrdude.exe: safemode: hfuse reads as FF

avrdude.exe: safemode: lfuse reads as 79
avrdude.exe: safemode: hfuse reads as FF
avrdude.exe: safemode: Fuses OK (E:FF, H:FF, L:79)

avrdude.exe done.  Thank you.

Mit

avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U flash:r:c:\temp\leuchtturm.hex:i -n -v

und

avrdude -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U eeprom:r:c:\temp\eedump.hex:i -n -v

konnte ich dann sogar den Inhalt des flashs und des eeproms in eine 
HEX-Datei auslesen (habe ich erstmal nicht angehangen, könnte ich aber). 
Und mit

avr-objdump.exe -m avr -D c:\temp\leuchtturm.hex > c:\temp\leuchtturm.asm

habe ich dann wahrscheinlich eine Art Assembler-Code erhalten der mglw. 
vom Umfang der Funktionen her "Sinn" ergibt (sorry, ich habe überhaupt 
keine Ahnung :-)

Weil ich schon soweit gekommen war, habe ich mal versucht den Inhalt von 
flash und eeprom in einen neuen ATtiny auf einem Breadboard zu flashen 
und mit

avrdude.exe -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U flash:w:leuchtturm.hex -v

und

avrdude.exe -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U eeprom:w:eedump.hex -v

hat das sogar fehlerfrei geklappt. Mit

avrdude.exe -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U lfuse:w:0x79:m -v

habe ich dann die fuses des neuen ATtiny genau so programmiert, wie beim 
Original. Alles ohne erkennbare Fehlermeldungen oder Probleme. Zur 
Kontrolle habe ich sogar noch einmal den Flash-Inhalt des neuen ATtiny 
wieder ausgelesen und die erhaltene HEX-Datei mit WinMerge mit der 
originalen HEX-Datei verglichen. Ergebnis, beide Dateien sind 100% 
identitisch.

Wenn ich schon soweit gekommen bin, dann könnte ich ja auch mal 
versuchen die ganze Leuchtturm-Schaltung nachzubauen (siehe Anhang). Für 
den vermeintlichen Kondensator habe ich wahlweise einen 10 oder 100 nF 
Kerko eingebaut. Als Diode habe ich entweder eine 1N4148 oder 1N4007 
eingebaut. Ich habe mich an meinen "Schaltplan" aus dem Thread 
Beitrag "Schaltung mit ATtiny13A aus Solar-Leuchtturm verstehen" gehalten, allerdings ohne 
dass ich einen Schalter oder den 0 Ohm Widerstand verbaut hätte.

Hier nimmt dann die Erfolgsstory ihr vermeintliches Ende. Wenn ich die 
Schaltung mit der Batterie und einer Solarzelle (im dunklen) verbinde, 
kann ich messen, dass der ATtiny 3.2 V (Batterie-)Spannung bekommt. Die 
LED zeigt aber nicht das gewünschte Verhalten, sondern leuchtet manchmal 
(eratisch) sehr schwach oder blink schnell sehr schwach und ich kann an 
dem entsprechenden Pin PB1 nur 0V messen (an dem originalen ATtiny kann 
ich die Spannungsänderung mit einem DMM messen). Also PWM läuft wohl 
nicht. Mein unbewiesener Eindruck ist, dass die MCU gar nicht läuft. 
Aber hier bin ich mit meinem rudimentären Wissen überfordert. Was müsste 
ich tun/messen, um den Fehler einzukreisen? Ist die Schaltung überhaupt 
richtig?

Das einzige was ich noch positives mitteilen kann ist, dass sich der 
neue ATtiny nach diesen ganzen Experimenten immer noch auslesen und neu 
programmieren lässt. Ganz kaputt habe ich ihn also noch nicht gemacht!

Viele Grüße und schwitzt nicht so doll,
Stefan

[Ingo W. (uebrig)]

Stefan M. schrieb:
> konnte ich dann sogar den Inhalt des flashs und des eeproms in eine
> HEX-Datei auslesen (habe ich erstmal nicht angehangen, könnte ich aber).
> Und mit

Hast du dir die Datei mal angeschaut?
falls sie nur aus "ff" besteht, dann ist der originale Käfer 
auslesegeschützt.

[Stefan M. (beefjerky)]

Ingo W. schrieb:
> Hast du dir die Datei mal angeschaut?
> falls sie nur aus "ff" besteht, dann ist der originale Käfer
> auslesegeschützt.

Ja, sowas hatte ich auch die ganze Zeit im Hinterkopf. Die HEX-Datei 
besteht nicht nur aus FF und ich nehme an, dass eine Datei die nur aus 
FF bestünde wahrscheinlich von avr-objdump.exe nicht verarbeitet werden 
würde, oder? Meine wurde verarbeitet, allerdings verstehe ich natürlich 
nichts von dem was in dieser Datei (AVR-Asemmbler?) steht.

VG,
Stefan

[Bilch (Gast)]

Stefan M. schrieb:
> Ingo W. schrieb:
>> Hast du dir die Datei mal angeschaut?
>> falls sie nur aus "ff" besteht, dann ist der originale Käfer
>> auslesegeschützt.
>
> Ja, sowas hatte ich auch die ganze Zeit im Hinterkopf. Die HEX-Datei
> besteht nicht nur aus FF und ich nehme an, dass eine Datei die nur aus
> FF bestünde wahrscheinlich von avr-objdump.exe nicht verarbeitet werden
> würde, oder? Meine wurde verarbeitet, allerdings verstehe ich natürlich
> nichts von dem was in dieser Datei (AVR-Asemmbler?) steht.
>
> VG,
> Stefan

Einfach die Datei hier posten.

[Stefan M. (beefjerky)]

Bilch schrieb:
> Einfach die Datei hier posten.

[c-hater (Gast)]

Ingo W. schrieb:

> Hast du dir die Datei mal angeschaut?
> falls sie nur aus "ff" besteht, dann ist der originale Käfer
> auslesegeschützt.

Das ist nur die halbe Wahrheit. Es ist bei Weitem nicht garantiert, das 
bei gelocktem Chip $ff gelesen wird. Nein, es wird vielmehr 
irgendwelcher Quatsch gelesen, bloß halt nicht der echte Inhalt.

Ich habe bei verschiedenen gelockten AVR8 schon alles mögliche gesehen. 
"Liefert nur $ff" kam dabei auch vor, das war aber war eher die Ausnahme 
als die Regel.

Stefan M. schrieb:

> allerdings verstehe ich natürlich
> nichts von dem was in dieser Datei (AVR-Asemmbler?) steht

Dann lerne es! Wenn man schon klauen will, muss man die nötigen 
Kompetenzen aufbauen. Du kannst kein Bankräuber sein, wenn deine einzige 
Kompetenz Nasenpopeln ist. So ist das nunmal.

Allerdings: wenn man die nötige Kompetenz hat, braucht man solchem 
lächerlichen Pimpelkram natürlich auch nicht mehr per RE zu klauen, das 
ist dann viel schneller selber "from scratch" programmiert...

[Bilch (Gast)]

Stefan M. schrieb:

> Bilch schrieb:
>> Einfach die Datei hier posten.

Die Datei enthält kein sinnvolles Programm.

Hinweis: auf den asozialen Troll (siehe "Kompetenz" oben) solltest Du 
nicht antworten.

[Stefan M. (beefjerky)]

Bilch schrieb:
> Die Datei enthält kein sinnvolles Programm.

Das ist sehr schade. Damit ist meine Geschäftsidee beim Teufel. Was 
mache ich jetzt mit 2t Sperrholz? ;-)

Ok, Spaß bei Seite. Wie kann man in der ASM-Datei erkennen ob das ein 
sinnvoller Code ist oder nicht? Gibt's da vielleicht ein paar einfache 
Tricks?

Ich wusste ja, dass es sowas gibt, deshalb frage ich mich, wie ich 
vorher hätte herausfinden können, dass das Auslesen nicht funktionieren 
wird? avrdude.exe scheint ja selbst mit -vvvv nicht den Status der Lock 
Bits auszugeben. Jetzt habe ich mal versucht mit

"C:\Program Files (x86)\Arduino\hardware\tools\avr\bin\avrdude.exe" -C "C:\Program Files (x86)\Arduino\hardware\tools\avr\etc\avrdude.conf" -c stk500 -p attiny13 -P COM7 -U lock:r:lock.hex:i -n -v

die Lock Bits auszulesen. Was dabei herauskommt sieht so aus:

:010000003CC3
:00000001FF

Sagt mir das irgendwas? Welches davon ist das Byte das die Lock Bits 
enthält?

VG,
Stefan

[Matthias S. (Firma: matzetronics) (mschoeldgen)]

Stefan M. schrieb:
> Wie kann man in der ASM-Datei erkennen ob das ein
> sinnvoller Code ist oder nicht?

Wenn du dir dein ASM File nochmal anschaust, siehst du, das in den 
Programmdaten nur hochgezählt und ein Teil der Programmadresse 
abgebildet wird. Das kann kein sinnvoller Code sein.

[c-hater (Gast)]

Stefan M. schrieb:

> Wie kann man in der ASM-Datei erkennen ob das ein
> sinnvoller Code ist oder nicht?

Man lernt Asm. Dann kann man das problemlos erkennen. Kannst du nicht.

> avrdude.exe scheint ja selbst mit -vvvv nicht den Status der Lock
> Bits auszugeben. Jetzt habe ich mal versucht mit

Doch, tut es.

> die Lock Bits auszulesen. Was dabei herauskommt sieht so aus:
>
>

> :010000003CC3
> :00000001FF
>

>
> Sagt mir das irgendwas? Welches davon ist das Byte das die Lock Bits
> enthält?

Das, in dem 3C steht. Wenn man wüßte, wie eine Hex-Datei aufgebaut ist, 
erkennt man das. Also noch eine Sache, die du nicht weisst...

Und übrigens: 3C bedeutet: LB1 & LB2 sind programmiert, was wiederum 
bedeutet:

> Further programming and verification of the Flash and
> EEPROM is disabled in High-voltage and Serial Programming
> mode. Fuse bits are locked in both Serial and High-voltage
> Programming mode. debugWire is disabled.

Sowas kann man übrigens dem Datenblatt entnehmen, was du offensichtlich 
auch nicht kennst.

Insgesamt sehr schlechte Voraussetzungen für einen Code-Klau...

[Georg M. (g_m)]

Den ATtiny13A kann man u.U. auch selbst programmieren.
Hier sind einige einfache Programmbeispiele:
https://blog.podkalicki.com/100-projects-on-attiny13/

[Dieter D. (Firma: Hobbytheoretiker) (dieter_1234)]

Im Datenblatt des Leuchtturmes steht bis zu 3000 Ladungen. Daher wäre es 
viel interessanter, wenn Du mal messen würdest bei welchen Schwellen die 
Abschaltung (Unter- & Überspannungsschutz) erfolgt.

Mit dem Auslesen des Programmcodes würde ich mich nicht mehr 
beschäftigen, sondern gleich die Algorithmen entwerfen für eine 
erweiterte Funktion des Teils. Ich würde das erweitern auf vier LED und 
über weiches Überblenden einen Dreheffekt simulieren oder einen Motor 
mit Spiegel einbauen (7,5° LED).

[Keeper (Gast)]

Dieter D. schrieb:



> Ich würde das erweitern auf vier LED und über weiches Überblenden einen
> Dreheffekt simulieren oder einen Motor mit Spiegel einbauen (7,5° LED).

Da der Leuchtturm sechs Fenster hat würde ich 6 LEDs nehmen.

[Stefan M. (beefjerky)]

Moin, zusammen!

c-hater schrieb:
> Und übrigens: 3C bedeutet: LB1 & LB2 sind programmiert, was wiederum
> bedeutet:
>
>> Further programming and verification of the Flash and
>> EEPROM is disabled in High-voltage and Serial Programming
>> mode. Fuse bits are locked in both Serial and High-voltage
>> Programming mode. debugWire is disabled.

Danke!

Dieter D. schrieb:
> Mit dem Auslesen des Programmcodes würde ich mich nicht mehr
> beschäftigen, sondern gleich die Algorithmen entwerfen für eine
> erweiterte Funktion des Teils. Ich würde das erweitern auf vier LED und
> über weiches Überblenden einen Dreheffekt simulieren oder einen Motor
> mit Spiegel einbauen (7,5° LED).

Keeper schrieb:
> Da der Leuchtturm sechs Fenster hat würde ich 6 LEDs nehmen.

Vielen Dank für die super Ideen! Ich hätte mich da jetzt eher erstmal an 
etwas Einfacheres gewagt. Schon allein die Blinkfrequenz ist nicht 
wirklich Leuchtturm-like. Das hätte ich erstmal geändert, aber Eure 
Ideen sind natürlich top!

Ich habe es inzwischen geschafft einen neuen ATtiny13 mit eigenem Code 
zu programmieren. Allerdings ist mir dabei aufgefallen, dass ich gar 
nicht so leicht Ausgaben auf einem seriellen Monitor erzeugen kann (ohne 
die ich das wohl nicht hinbekommen werde). Der Core den ich für Arduino 
verwende (https://github.com/MCUdude/MicroCore) kann solche Ausgaben 
aber wohl erzeugen, ich muss nur mal sehen, wie ich an die Ausgaben dran 
komme. Na, mal sehen wie weit ich komme...

Dieter D. schrieb:
> Im Datenblatt des Leuchtturmes steht bis zu 3000 Ladungen. Daher wäre es
> viel interessanter, wenn Du mal messen würdest bei welchen Schwellen die
> Abschaltung (Unter- & Überspannungsschutz) erfolgt.

Mit dem Ziel Strom und damit Ladezyklen zu sparen? Du meinst bei welcher 
Batteriespannung die LED abgeschaltet wird? Geladen wird die Batterie 
aber natürlich immer wenn die Solarspannung minus Diodenspannung größer 
ist als die Batteriespannung. Das kann ich zumindest mit dieser 
Schaltung nicht verhindern und so kommen dann natürlich viele Ladezyklen 
zustande. Mit Stromsparen allgemein und sowas wie Standby oder 
Schlafmodi von MCUs habe ich mich noch nie beschäfftigt, wäre aber 
natürlich auch ein interessanter Punkt.

Einen schönen Sonntag!
Stefan

[Peter D. (peda)]

Ingo W. schrieb:
> Hast du dir die Datei mal angeschaut?
> falls sie nur aus "ff" besteht, dann ist der originale Käfer
> auslesegeschützt.

Bei gelockten AVRs wird ein Adressbyte gelesen, d.h. aufsteigende 
Zahlenwerte.