atmega328 avrdude verification error

[Paul G. (paul_g210)]

Hi

Ich habe ein Problem mit meinem Atmega328.
Wenn ich einen "bestimmten" Sketch per avrdude hochladen will
bekomme ich eine Fehlermeldung:

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0x00 != 0x0c
avrdude: verification error; content mismatch

avrdude: safemode: lfuse changed! Was 22, and is now 0
Would you like this fuse to be changed back? [y/n]

Ich habe dann bisher mit CTRL+R abgebrochen...


Kurz zur Vorgeschichte:
Ich habe einem Arduino Nano den Atmega328 entlötet
und auf meine selbst entworfene  Platine gelötet. Kurz und knapp
wollte ich einfach nur den Atmega haben und nicht den ganzen
Schnulz vom Arduino Board um die Stromaufnahme auf ein minimum zu 
reduzieren. Der Atmega läuft außerdem nun mit 3.3V. Logischerweise 
schreibe ich meine *.hex Dateien nun per UsbAsp Clone auf den Atmega und 
nicht via "hochladen" in der Arduino IDE. Ich habe ihn erfolgreich
auf 1Mhz interner Oszillator und Ausgabe des Systemtakts auf PB0 
programmiert.  Meine Fuses sind damit:

E:FF, H:D9, L:22

Zum programmieren benutze ich die Arduino IDE und lasse mir dann den 
Sketch als hex exportieren.
Damit auch das Timing (1MHz) stimmt habe ich diese Anweisung in der 
"boards.txt" geändert:

nano.build.f_cpu=1000000L

Ein einfacher Blink Sketch der PD1 und eine daran gehängte LED im 
Sekunden Takt blinken lässt funktioniert tadellos:

void setup() {
  // put your setup code here, to run once:
DDRD = B00000010; //set PD1 as output
}

void loop() {
  // put your main code here, to run repeatedly:

  PORTD = B00000010;
  delay(500);
  PORTD = B00000000;
  delay(500);
}

avrdude gibt keinerlei Fehlermeldungen raus und der Sketch läuft:

...
Reading | ################################################## | 100% 0.33s

avrdude: verifying ...
avrdude: 638 bytes of flash verified

avrdude: safemode: Fuses OK (E:FF, H:D9, L:22)

avrdude done.  Thank you.

Nun wollte ich mein SSD1306 Oled an dem Atmega testen, habe alle libs in 
Arduino IDE runtergeladen und ein minimalen Sketch geschrieben.

#include <SPI.h>
#include <Wire.h>
#include <Adafruit_GFX.h>
#include <Adafruit_SSD1306.h>

#define SCREEN_WIDTH 128 // OLED display width, in pixels
#define SCREEN_HEIGHT 64 // OLED display height, in pixels

// Declaration for an SSD1306 display connected to I2C (SDA, SCL pins)
#define OLED_RESET     4 // Reset pin # (or -1 if sharing Arduino reset pin)
Adafruit_SSD1306 display(SCREEN_WIDTH, SCREEN_HEIGHT, &Wire, OLED_RESET);



void setup() {
  display.begin(SSD1306_SWITCHCAPVCC, 0x3D); // Address 0x3D for 128x64
  display.clearDisplay();

  display.setTextSize(1);             // Normal 1:1 pixel scale
  display.setTextColor(WHITE);        // Draw white text
  display.setCursor(0,0);             // Start at top-left corner
  display.println("Hello, world!");
  display.display();
}

void loop()
{}

Wenn ich nun diesen Sketch exportiere und versuche auf den Atmega zu 
schreiben bekomme ich die obige Fehlermeldung...
Warum versucht gerade dieser Sketch die Fuses beim hochladen zu ändern 
und der Blink Sketch nicht? Warum will er die Fuses auf 0 ändern?

[Stefan F. (Gast)]

Ich glaube nicht, dass er die Fuses wirklich ändern will. Für mich sieht 
das eher so aus, dass die Kommunikation gestört ist und avrdude daher 
"denkt", die Fuse wäre unabsichtlich verändert worden.

Bei der Kombination 3,3V und USBASP geht bei mir direkt eine rote Lampe 
an. Ist dir bewusst, dass die allermeisten USBASP trotz 3,3V Jumper 
immer mit 5V Signalen arbeiten?

[Paul G. (paul_g210)]

Stefanus F. schrieb:

> Bei der Kombination 3,3V und USBASP geht bei mir direkt eine rote Lampe
> an. Ist dir bewusst, dass die allermeisten USBASP trotz 3,3V Jumper
> immer mit 5V Signalen arbeiten?

Upps,Danke! das ist mir neu... Schnell mal auf 5V zurückgejumpert und 
tada,
keine Fehlermeldung mehr.

Wo genau ist da das Problem wenn UsbAsp mit 5V anstatt mit 3.3V 
kommuniziert? Oder sendet er dann die MISO und MOSI mit 3.3V und VCC mit 
5V oder andersrum?

[Stefan F. (Gast)]

Paul G. schrieb:
> Wo genau ist da das Problem wenn UsbAsp mit 5V anstatt mit 3.3V
> kommuniziert?

Du hast mich missverstanden. Die meisten USBASP kommunizieren immer mit 
5V, obwohl der Jumper auf 3,3V gesteckt ist. Der Jumper steuert nur die 
Versorgungsspannung für das Target.

Es macht aber keinen Sinn, das Target mit 3,3V zu versorgen und dann mit 
5V Signalen zu arbeiten. Damit riskiert man bloß, etwas kaputt zu 
machen. Denn alle Signale dürfen maximal 0,5V höher sein, als die 
Versorgungsspannung (gilt für beide Seiten, siehe "Electrical 
Characteristics" im Datenblatt).

Außerdem sollte dieser Vtarget PIN eigentlich genau anders herum 
arbeiten. Das Target soll damit den Programmieradapter versorgen, eben 
damit er sich an dessen Versorgungsspannung anpasst.

Diese USBASP Programmer sind schön billig aber in meinem Augen eine 
grobe Fehlkonstruktion. Die Erkenntnis ist nicht neu und es gibt längst 
Lösungen die nur wenige Cent mehr kosten.Trotzdem stellen Sie ihre 
Produktion nicht um. So ist das mit dem Chinaschrott. Manche Sachen sind 
gut, aber es kommt leider auch sehr viel schlechtes aus Asien.

[Paul G. (paul_g210)]

Stimmt, du hast recht, ich habe es gerade auf meinem Ozzi gesehen das 
VCC 3.3V hat und MOSI mit 5V sendet egal was ich jumper...

Dann schreibe ich die Programme halt mit 5V VCC und stecke so lange alle 
3.3V Peripherie ab und dann im Normalbetrieb wieder drann...

[Stefan F. (Gast)]

Paul G. schrieb:
> Dann schreibe ich die Programme halt mit 5V VCC und stecke so
> lange alle 3.3V Peripherie ab und dann im Normalbetrieb wieder drann...

Kannst du so machen. Oder du schleifst 180Ω Widerstände in die 
Signal-Leitungen ein. Die begrenzen dann den Strom, der durch die 
Überspannung fließt. Ist zwar nicht ganz sauber aber geht.