Atmega328PB nicht flashbar, ISP Pinning?

[Tom (Gast)]

Hallo,

ich hab schon einige Atmegas verbaut und Programmiert, jedoch steh ich 
beim Atmega328PB irgendwie auf dem Schlauch.
Hab jetzt meine Platinen bekommen aber ich kann ihn über den myAVR ISP 
Programmer nicht ansprechen.

Jetzt mal als erstes die Grundlegende Fragen... welche Pins am Chip 
werden hier benötigt?

Im Datenblatt steht die SPI Schnittstelle mit folgendem Pinning... siehe 
Anhang

Flashen wollte ich ihn mit dem myAVR ProgTool, hier kann man nur den 
atmega328P auswählen. http://shop.myavr.de/index.php?sp=download.sp.php

Ich hab meinen so verkabelt:

ISP -------- ATMEGA328PB
1 MISO ---- PIN 16
2 VCC ----- PIN 4 und 18
3 SCK ----- PIN 17
4 MOSI ---- PIN 15
5 RESET --- PIN 29
6 GND ----- PIN 5 und 21

[Marc V. (Firma: Vescomp) (logarithmus)]

Tom schrieb:
> Ich hab meinen so verkabelt:
 Stimmt so.

> Hab jetzt meine Platinen bekommen aber ich kann ihn über den myAVR ISP
> Programmer nicht ansprechen.
 Platinen überprüfen.

> Flashen wollte ich ihn mit dem myAVR ProgTool, hier kann man nur den
> atmega328P auswählen.
 Trotzdem sollte es gehen.
 M328P auswählen, der Prommer sollte nach Verbinden zumindest falsche
 Signature Bytes melden.

[Luca E. (derlucae98)]

Pullup am Reset?

[Stefan F. (Gast)]

Luca E. schrieb:
> Pullup am Reset?

Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.

[Horst (Gast)]

Hast Du denb ISP-Takt passend zum Prozessortakt eingestellt? Also nicht 
mehr als 1/4 und damit max 250kHz bei neuen ATMega

[Tom (Gast)]

Pullup am Reset ist vorhanden

Ich denke es liegt am Programmer... evtl. schickt dieser falsche Daten 
oder das Timing zum Chip passt nicht.
Der 328PB ist anscheinend etwas anders was das Timing angeht.

Im Datenblatt steht was von Bootloader welcher die zusätzlichen UARTS 
und SPI schnittstellen verwaltet... aber ich werde da nicht ganz schlau 
daraus...

Hier das Datenblatt
http://ww1.microchip.com/downloads/en/DeviceDoc/40001906C.pdf

[Stefan F. (Gast)]

> Der 328PB ist anscheinend etwas anders was das Timing angeht.

Das würde mich überraschen, denn er wird als Drop-In-Replacement für den 
ATmega328P gehandelt.

[Tom (Gast)]

Stefanus F. schrieb:
> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.

Die sind aus dem Datenblatt von Microchip, warum sollten die falsch 
sein?

[Stefan F. (Gast)]

Tom schrieb:
>> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.
> Die sind aus dem Datenblatt von Microchip, warum sollten die falsch
> sein?

Weil die richtigen Pins PB3, PB4 und PB5 sind. Steht auch in der Tabelle 
unter Zeichnung. Vergleiche mit dem Datenblatt vom ATmega328P.

Als das noch in der Hand von ATmel lag, was die Zeichnung noch korrekt: 
https://www.rlocman.ru/i/File/2016/03/02/Atmel-42397-8-bit-AVR-Microcontroller-ATmega328PB_Datasheet.pdf 
(ohne falsche Portnummern).

Seit Microchip an den Datenblättern herum fummelt, wird geschlampt, was 
das Zeug hält. Das ist schon das dritte irreführende Bild, auf das ich 
gestoßen bin.

[Marc V. (Firma: Vescomp) (logarithmus)]

Tom schrieb:
> Stefanus F. schrieb:
>> Die Angaben PB5, PB6 und PB7 in Figure 23-6 sind sicher falsch.
>
> Die sind aus dem Datenblatt von Microchip, warum sollten die falsch
> sein?

 Reg dich nicht auf, du hast es richtig angeschlossen.

[Bernard_B (Gast)]

Du hast nicht 2 Stück 100nF Keramikkondensatoren an Vcc vergessen? (Pin 
4 und Pin 18).
Als nächstes ein 10 nF zu AVcc. Aber ohne die sollten es immerhin keine 
so drastischen Ergebnisse geben.

[Veit D. (devil-elec)]

Hallo,

leider steht hier keine Lösung des Problems. Stand nämlich soeben vor 
selbigen. Bei mir lag es daran das ich meinen mkII Treiber vor einer 
Weile mit dem Zadigtool behandelt hatte. Musste ich machen damit er in 
der Arduino IDE nutzbar wurde. Atmel Studio erkennt damit zwar den mkII, 
kann aber sonst nichts machen. Erst als ich den Treiber mit dem 
Zadigtool zurückgeändert habe klappt es in AS7 wieder.

Das Problem ist damit unabhängig vom µC. Vielleicht hilft es ja 
jemanden.

Und ja das aktuelle Manual ist grottig. Microchip versaut was vorher 
gestimmt hat.

[c-hater (Gast)]

Veit D. schrieb:

> Und ja das aktuelle Manual ist grottig. Microchip versaut was vorher
> gestimmt hat.

Da kannst du so dermaßen einen 'drauf lassen. Glücklich ist jeder, der 
die alten Atmel-DBs archiviert hat. Ja, da war auch nicht immer alles 
korrekt, aber gegen das, was diese vollkommen unfähigen MC-Plinse 
liefern, sind die so wertvoll und wertstabil wie Gold.

Wenn man das Elend sieht, wird klar, warum ich mit den PICs nie warm 
werden konnte, obwohl zumindest einige davon nominell durchaus attraktiv 
im Vergleich zum Atmel-Sortiment waren.

Aber was nützt mir ein Chip, bei dem das Datenblatt gequirlte Scheisse 
erzählt? Der kann noch so gut sein, für mich ist er de facto 
unbrauchbar.

[Stefan F. (Gast)]

c-hater schrieb:
> Glücklich ist jeder, der die alten Atmel-DBs archiviert hat.

Kann ich bestätigen. Die neuen Datenblätter sind bunter, aber enthalten 
neue Fehler. Warum haben die das überhaupt gemacht, hat irgendein 
Entwickler mehr Farbe angefordert?

[c-hater (Gast)]

Stefanus F. schrieb:

> Die neuen Datenblätter sind bunter, aber enthalten
> neue Fehler. Warum haben die das überhaupt gemacht, hat irgendein
> Entwickler mehr Farbe angefordert?

Nö, das war ganz sicher eine Idee der Marketing-Abteilung, vielleicht 
sogar des höheren Managements. Letzteres hat aber in jedem Fall 
entschieden, dass es so laufen soll.

Und auf jeden Fall waren all die nicht beteiligt, die eine kompetente 
Meinung zur Sache hätten äußern können, also diese unbeliebten 
Technik-Leute, die alles nur nur sinnlos zerreden...

Merke: Nichts erleichtert das Fällen von Entscheidungen mehr als die 
Abwesenheit jeglichen Sachverstands.

Das allerdings ist kein alleiniges Problem von MC, nein, man findet es 
in fast jeder Firma. Je größer sie ist, desto weniger geht es bei so 
einer Entscheidungsfindung um technische Sachverhalte. Eben deshalb, 
weil die Entscheider davon sowieso rein garnix verstehen...

[Veit D. (devil-elec)]

Hallo,

das mit den farbigen Blockbildern am Anfang der Manuals fiel mir damals 
auch sofort auch kurz nach der Übernahme. Damals dachte ich, naja warum 
nicht. Etwas Farbe kann ja nicht schaden. Was ich aber niemals vertehen 
werde ist warum Dinge die Richtig sind ins Falsche geändert werden. Da 
muss jemand bewusst drin rumgepfutscht haben.
Was Schade ist, den die 8Bitter gefallen mir nachwievor, auch die neue 
Mega0Serie. Die STM32Bit u.ä. sind mir leider zu kompliziert im Aufbau, 
was ich auch nie ausreizen würde. Auch weil ich gerade mit der 
Mega0Serie warm werde.