Im Bild seht Ihr meinen Aufbaut:
Atmega1281 ist Master, f_spi = f_osc/128, f_osc=16MHz
Atmega16A ist Slave, f_osc=12MHz
Toolchain: AVR Studio 4.19, JTAG ICE MKII
Problem:
sobald beide uCs per SPI verbunden werden (oder sobald per
singlestepping der SPI auf dem Atmega16A initialisiert ist) ist der
Slave-uC nicht mehr per JTAG ansprechbar.
Für den Slave sind 2 Interrupts registert:
1) SPI hat neues byte empfangen
2) positive Flanke auf INT2
Ziel:
der Atmega16A empfängt die SPI-Daten im Interrupt und speichert sie in
einen Puffer.
Ich bring den Thread nochmal hoch ...
Niemandem fällt was falsches auf?
- Verdrahtung?
- SPI mode
- Interrupt
- Lese-Sschreib - Reihenfolge?
Ich krieg's einfach nicht ans Laufen
(Clock, Daten, ChipSelect sieht auf dem Oszi erstmal unauffällig aus)
JTAG sollte doch eigentlich unabhängig vom Programm laufen, oder?
Werden die JTAG-Pins für irgendwas anderes benutzt?
Wann tritt das auf? Wenn beide verbunden sind, wenn SPI initialisiert
wird oder in beiden Fällen?
Ja.. Jtag sollte unabhängig sein... hatte schon einige Sitzationen bei
AVRs, wo das so war.
Die Pins werden exklusiv genutzt, hängt sonst nichts dran.
Jtag am Slave hängt, sobald SPI mit interrupts initialisiert ist and
Spi-Traffic kommt. Hat das die Frage beantwortet?
Hi
>Nun ja. MOSI und MISO werden gekreuzt. Schau mal den internen Aufbau an.>Schieberegister.
Wo ist im Anhang (stammt vom ATMega16A des TO) etwas gekreuzt?
MfG Spess
Tatsaechlich. Der Mega vertauscht die Pins intern je nach Mode, Slave
oder Master. Besten Dank. Ich konnte bisher einen Slave mit einem
controller nachzubilden vermeiden. Das ist mangels Buffer etwas vom
Muehsamsten das es gibt.
Zitronen F. schrieb:> Wenn ich also einen Mega16 mit einem Mega16> verbinde muss gekreutzt werden.
Mit so einer Scheisse wirst du kein einziges Byte übertragen.
Zitronen F. schrieb:> Bei einem Controller sind die Anschriften der Pins aber fest, so wie> wenn er Master waere. Wenn ich also einen Mega16 mit einem Mega16> verbinde muss gekreutzt werden. Sonst habe ich Input auf input und
Das ist aber genial.
Ob Master oder Slave wird mit MSTR in SPCR bestimmt.
Und SCK wird vom Master generiert und vom Slave gesampelt.
Es können weder 2 Master noch 2 Slaves miteinander kommunizieren.
Marc V. schrieb:> Es können weder 2 Master noch 2 Slaves miteinander kommunizieren.
Zitronen F. kann das aber trotzdem, denn er ist der
Chuck Norris der Mikrocontroller-Elektronik, und Chuck Norris
kann bekanntlich alles.
SPI_Slave schrieb:> oder Stück für> Stück den möglichen Fehlerraum verringern kann?
Mir ist aufgefallen dass du für ein Ereignis zwei Interrupts
installierst. Das müsste ja mit dem SPI Interrupt alleine
auch funktionieren.
Könnte sein dass die beiden ISRs sich gegenseitig stören?
Habe es nicht näher betrachtet.
Jedenfalls kannst du nicht einfach mit dem Master den Slave
mit Daten "vollballlern" in der Hoffung dass der Slave so
schnell ist dass er nicht überfahren wird.
SPI_Slave schrieb:> Jtag am Slave hängt, sobald SPI mit interrupts initialisiert ist and> Spi-Traffic kommt.
Das heißt, wenn ein Master vorhanden ist.
Was passiert, wenn du den Master weglässt, also elektronisch entfernst?
Was passiert, wenn der Master elektrisch verbunden, aber der Slave nicht
auf SPI initialisiert ist.
Ich versuche rauszufinden, ob es ein Softwareproblem ist, was ich mit
meinem begrenzten Wissen bei JTAG ausschließen würde, oder ein
elektrisches Problem, dass der Master aus irgendeinem Grund den Slave
stört.
SPI_Slave schrieb:> Habt Ihr Ideen, wie ich das ganze noch eingrenzen kann oder Stück für> Stück den möglichen Fehlerraum verringern kann?
Ich würde der Reihe nach gehen.
1. Beide verbinden.
2. SPI im Slave initialisieren.
3. Daten vom Master senden und sehen.
4. Slave mit Interrupts initialisieren, ohne Daten zu senden.
5. Salve initialisieren und Daten senden.
Ab einem dieser Schritte sollte es Probleme geben (sonst wäre ja alles
gut).
Außerdem nochmal, da es die Diskussion oben gab, sicherstellen, dass
MOSI nicht mit MISO verbunden ist.
Code Betrachta schrieb:
> Mir ist aufgefallen dass du für ein Ereignis zwei Interrupts> installierst. Das müsste ja mit dem SPI Interrupt alleine> auch funktionieren.
Ich nutze Int2, um die steigende Flanke des ChipSelect zu finden.
Sollte es einfacher gehen, sich mit AVRs im Slave-Mode auf den SPI-Frame
zu synchronisieren, bin ich für Vorschläge offen :-)
> Könnte sein dass die beiden ISRs sich gegenseitig stören?> Habe es nicht näher betrachtet.
Unwahrscheinlich, da sie auf unterschiedliche Events triggern, die auch
zeitlich nicht zusammen auftreten sollten.
> Ich würde der Reihe nach gehen.> 1. Beide verbinden.> 2. SPI im Slave initialisieren.> 3. Daten vom Master senden und sehen.> 4. Slave mit Interrupts initialisieren, ohne Daten zu senden.> 5. Salve initialisieren und Daten senden.
Es hakt schon bei 3.)
außerdem bekomme ich vom compiler diese Meldung (ist mir bislang nicht
aufgefallen):
1
warning: 'SPI_STC_vect' appears to be a misspelled signal handler
Hab mir das auch mal im Dissassembly angeschaut (Bild im Anhang).
An diese Stelle springt er, sobald der code
1
sei();
durchlaufen hat.
Deutet darauf hin, dass er seine Interrupt-Funktion nicht richtig auf
die jump table der ISRs setzt.
Was mach ich da falsch?
also sobald der SPIE in SPCR gesetzt ist und die Interrupts mit sei()
aktiv sind, rennt er in das Problem
(da der angeschlossene SPI Master continuierlich Frames sendet)
oh neee ...
ich hab des Rätsels Lösung - es ist so peinlich, dass ich es kaum zum
besten geben möchte, aber Ihr habt alle reingeschaut und Zeit verbracht,
da gehört es sich auch das ganz aufzulösen:
1
Atmega16A = worauf ich kompiliert und debuggt hab
2
Atmega16 = was wirklich als HW vorliegt
Dummerweise matchen aus die Signatures, sodass es mir dabei nicht
aufgefallen ist.
Ich danke Euch für die Gedanken/Ideen!
Hi
>Atmega16A = worauf ich kompiliert und debuggt hab>Atmega16 = was wirklich als HW vorliegt
Es gibt eine passende AppNote:
AVR522: Migrating from ATmega16 to ATmega16A
Da finde ich aber nichts drin, was deinen Fehler hervorrufen könnte.
MfG Spess
SPI_Slave schrieb:> Der atmega16a hat den SPI interrupt auf Vector 14,> der atmega16 hat ihn auf 10
Sagt wer?
Der SPI/STC Vektor befindet sich bei beiden auf Adresse 0x0014.
Aber:
ATmega16 = SPI_STC_vect.
ATmega16A = SPISTC_vect.
Deswegen die Warnung und der Jump nach RETI.
SPI_Slave schrieb:> Wo hast Du Deine Info her?
Ich glaube das steht in iom16.h und iom16a.h dateien.
Das habe ich schon vor langer Zeit geändert, aber mindestens seit 4-5
Jahren keinen M16 oder M16A benutzt, deswegen bin ich mir auch nicht
ganz sicher darüber.
AVR_SPI_Master_Slave.png
(5,5 KB)
