Forum: Mikrocontroller und Digitale Elektronik SPI bekämpft ISP, myAVR


von Marc S. (darkchaos)


Lesenswert?

Hey Leute,
Ich zerbreche mir schon seit Stunden den Kopf warum mein SPI nicht so 
will wie ich, obwohl es ja vermeintlich einfach sein sollte.

Das Symptom war, dass MOSI ständig High ist (4.7V, bei Vcc von 5.2V) und 
CLK ständig 0V ist (Der AVR sollte Master sein und Schieberegister 
ansteuern).

Was mir parallel dazu auffiel, ist dass sich mein Programmer (der myAVR 
USB MK2) jedes mal zerschossen hat ("Die Signatur konnte nicht 
ausgelesen werden.") sprich: Weder Fuses noch Flash lesen und schreiben.

Hier hilft (warum auch immer) nur der PC Neustart und herumprobieren mit 
USB ein- und ausstecken bzw. externe Stromversorgung an und aus.

Was mir nun dämmert: Es ist doch gut möglich dass die Pins sowohl vom 
Programmer als auch "von mir" belegt sind. Kann es sein, dass wenn ich 
in den Master Mode wechsle, dass dann der Treiber abschmiert?

Kann ich dagegen etwas anderes tun außer den AVR aus dem Programmer zu 
nehmen und ihn mal so zu testen?

von Stefan K. (stefan64)


Lesenswert?

Du musst den SS Pin als Ausgang beschalten, sonst wechselt die SPI bei 
falschem SS Pegel in den Slave-Mode.

Gruß Stefan

von Marc S. (darkchaos)


Lesenswert?

Stefan K. schrieb:
> Du musst den SS Pin als Ausgang beschalten, sonst wechselt die SPI bei
> falschem SS Pegel in den Slave-Mode.
>
> Gruß Stefan

Das habe ich bereits getan, so sieht meine Initialisierung aus
1
#define spi_master_init() DDRB = (1 << SPI_MOSI_PIN) | (1 << SPI_SCK_PIN) | (1 << SPI_SS_PIN); \
2
  SPCR = (1 << SPE) | (1 << MSTR) | (SPI_LSB_FIRST << DORD) | (SPI_CLOCK_SPR0 << SPR0) | (SPI_CLOCK_SPR1 << SPR1) \
3
  | (0 << CPOL); \
4
  spi_nonblocking(0x0); // write, so SPIF is available

Danach ist es in Dauerschleife eine Kombination dieser beiden:
1
#define spi_nonblocking(data) SPDR = data;
2
#define spi_block_ready() while(!(SPSR & (1 << SPIF)));


Ich habe jedoch gerade gelesen, dass der Programmer ja ein USB->USART 
Interface ist und der Bootloader so programmiert werden könnte, d.h. ich 
weiß jetzt erst nicht, ob es deswegen zu SPI Problemen kommt, aber bei 
den wenigen Pins die so ein Atmega8A hat, kann es schon sein, dass sich 
USART/SPI/ISP überlagern bzw. behindern, oder?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

klemm doch einmal alle fremden Signale von der ISP Schnittstelle ab. 
Schließe nur den Programmer dort an. Was passiert?

Die ISP Schnittstelle ist zudem keine UART sondern SPI.

Der Programmer zieht, wenn aktiv, per Reset den µC in den 
Programmiermodus. Das Programm auf den µC ist in dem Moment völlig egal.

Was noch sein kann, deine beschaltenen Signale am ISP kann dein 
Programmer nicht im Pegel runterziehen. Hast du Schutzwiderstände 
dazwischen?
Bei Doppelbelegung gibts das zubeachten. Deswegen erstmal nur mit 
Programmer am ISP testen.

von Marc S. (darkchaos)


Lesenswert?

Veit D. schrieb:
> klemm doch einmal alle fremden Signale von der ISP Schnittstelle ab.
> Schließe nur den Programmer dort an. Was passiert?

Mir ist nicht 100% klar wie das gemeint ist, im Prinzip habe ich dieses 
Board: http://shop.mymcu.de/index.php?sp=article.sp.php&artID=40

Ich nutze es genau so, ohne externe Beschaltung, ich hatte lediglich ein 
Oszilloskop an PORTB3 und PORTB5 hängen.

(Ich möchte nicht ausschließen, dass ich das Oszi nicht korrekt bedient 
habe, aber egal bei welchen Einstellungen habe ich nicht wirklich einen 
größeren Spannungsabfall gesehen, und bei CPOL = 0 und generell müsste 
ja eher alles auf GND liegen)

Veit D. schrieb:
> Der Programmer zieht, wenn aktiv, per Reset den µC in den
> Programmiermodus. Das Programm auf den µC ist in dem Moment völlig egal.

Hm, kann natürlich sein, dass der Treiber/Die Programming Software (AVR 
Studio untersützt AVR910 nicht mehr) generell unter Windows 10 ein paar 
Problemchen hat und das SPI Problem ein ganz anderes ist.

Kann ich irgendwie SPI mit Atmel Studio so simulieren, dass ich sehe ob 
es klappen würde? Also ich sehe zwar wie die Statusregister gesetzt 
werden, aber kann ich z.B. den Pegel von MOSI irgendwo plotten?

von Axel S. (a-za-z0-9)


Lesenswert?

Marc S. schrieb:
> Ich zerbreche mir schon seit Stunden den Kopf warum mein SPI nicht so
> will wie ich, obwohl es ja vermeintlich einfach sein sollte.
>
> Das Symptom war, dass MOSI ständig High ist (4.7V, bei Vcc von 5.2V) und
> CLK ständig 0V ist (Der AVR sollte Master sein und Schieberegister
> ansteuern).
>
> Was mir parallel dazu auffiel, ist dass sich mein Programmer (der myAVR
> USB MK2) jedes mal zerschossen hat ("Die Signatur konnte nicht
> ausgelesen werden.") sprich: Weder Fuses noch Flash lesen und schreiben.

Kann es sein, daß du das SPI Interface deines µC benutzen willst, 
während du gleichzeitig den ISP-Programmer angeschlossen hast? DAS GEHT 
NICHT.

von Pandur S. (jetztnicht)


Lesenswert?

Man kann gleichzeiting den Programmer angeschlossen haben und SPI 
bedienen.

Unter der Voraussetzung, dass die SPI Signale des Programmers 
softwaremaessig  nichts zerschiessen. Dies kann man verhindern, indem 
der Reset verwendet wird. Der Reset ist beim Programmieren LOW und im 
Betrieb HIGH.
Der Programmer sollte im normalen Mode, dh nicht-Programmieren die 
Leitungen tristate haben.
Dann sollten die SPI Leitungen des Programmers mit 100 Ohm geschuetzt 
sein, falls denn der Prozessor gegen den Programmer arbeiten sollte.

Alternativ kann man die Leitungen MOSI und MISO auch mit einem MUX, wie 
dem 2G126 zwischen Programmer und Peripherie umschalten indem man den 
Reset als Select verwendet.

: Bearbeitet durch User
von Stefan F. (Gast)


Lesenswert?

Welchen Programmieradapter verwendest du?
Und zeige uns deinen Schaltplan!

von Heinz B. (Firma: Privat) (hbrill)


Lesenswert?

stehen auch die Schalter des Mäuseklavieres
auf dem MKII richtig ?
Da gibt es ja verschiedene Modi.

von Axel S. (a-za-z0-9)


Lesenswert?

Sabberalot W. schrieb:
> Man kann gleichzeiting den Programmer angeschlossen haben und SPI
> bedienen.
>
> Unter der Voraussetzung, dass die SPI Signale des Programmers
> softwaremaessig  nichts zerschiessen.

Dieser Satz ergibt überhaupt keinen Sinn.

> Dies kann man verhindern, indem
> der Reset verwendet wird. Der Reset ist beim Programmieren LOW und im
> Betrieb HIGH.

Das hat überhaupt nichts mit dem Problem zu tun.

> Der Programmer sollte im normalen Mode, dh nicht-Programmieren die
> Leitungen tristate haben.

Eben. Er "sollte". Wenn aber nicht, dann versuchen µC und Programmer die 
MOSI und SCK Pins auf verschiedene Pegel zu ziehen. Was mindestens die 
SPI-Kommunikation stört und im schlimmsten Fall einen der beiden tötet.

von c-hater (Gast)


Lesenswert?

Axel S. schrieb:

> Kann es sein, daß du das SPI Interface deines µC benutzen willst,
> während du gleichzeitig den ISP-Programmer angeschlossen hast? DAS GEHT
> NICHT.

Also bei mir geht das sehr wohl. Und zwar sogar gleich mit DREI völlig 
unterschiedlichen ISP-Programmern (1x Eigenbau Primitivst-Interface zu 
Com-Port, 1x Eigenbau auf V-USB-Basis (sehr ähnlich 
"AVR-Doper"-Hardware) und 1x Diamex-USB-Stick).

Der einzige Trick ist:  Alle SPI-Geräte am Bus sind im Resetfall 
zuverlässig auf "inaktiv" durch Pulldowns am jeweiligen /CS und SCK und 
MOSI vom Programmer sind mit je (mindestens) 220Ohm an den Bus 
angekoppelt.

Und ja: Das Programmieren funktioniert sowohl mit dem 
AVR-Doper-Verschnitt als auch mit dem Diamex sogar mit 1,8MHz SPI-Takt 
völlig problemlos. Trotz der für den möglichen Takt potentiell ziemlich 
schädlichen Angstwiderstände...

Fazit, wie so oft: man muß einfach nur wissen, was man tut... Rechnen 
vorher und Messen nachher z.B. sind ziemlich gute Ansätze, um auch 
schaltungstechnisch etwas grenzwertige Sachen zum Laufen zu bringen...

von c-hater (Gast)


Lesenswert?

c-hater schrieb:

> zuverlässig auf "inaktiv" durch Pulldowns am jeweiligen /CS und SCK und

Das sollte natürlich "Pullups" heißen...

von Marc S. (darkchaos)


Lesenswert?

Es ist mir peinlich dies zu sagen, aber das Problem ist gelöst.
TLDR: Der Atmega war einfach kaputt (bzw. halb kaputt, warum auch 
immer).

Jedenfalls habe ich den Fehler mit der Signatur die nicht gelesen werden 
kann gegoogled und kam zum Schluss, dass nicht der Programmer das 
Problem war sondern ISP zum AVR nicht richtig funktioniert. Also einfach 
mal einen neuen Atmega eingesteckt und da klappt alles.

Dazu muss ich allerdings sagen, dass ich (weil Schieberegister) nur MOSI 
nutze und weder MISO noch SS, da könnte es in der Tat nochmal 
problematischer werden.

Aber letztenendes bin ich froh, dass die Lösung so trivial war, dass ich 
nicht darauf gekommen bin. Einfach mal nen neuen µC testen...

Danke an alle für eure Hilfe und Zeit :)

von Peter D. (peda)


Lesenswert?

Marc S. schrieb:
> Der Atmega war einfach kaputt (bzw. halb kaputt, warum auch
> immer).

Wobei der nur seltenst wirklich kaputt ist, sondern einfach nur die 
Fusebits falsch gesetzt. Mit einem Fusedoctor kann man ihn 
wiederbeleben.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.