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.
Angehängte Dateien:
-
AVR_SPI_Master_Slave.png
5,5 KB
SPI_Slave schrieb: > Im Bild seht Ihr meinen Aufbaut: ... und deine Sourcen brauchen wir auch noch ... Es sei denn es soll hier ein Ratespiel werden.
hier die FW der beiden uC ... reduziert auf den SPI Anteil
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?
Nun ja. MOSI und MISO werden gekreuzt. Schau mal den internen Aufbau an. Schieberegister.
Angehängte Dateien:
-
SPI.jpg
20 KB
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
Nirgends. Was man aus den Bezeichnungen eigentlich auch ableiten kann: M aster O ut S lave I n M aster I n S lave O ut Oliver
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.
:
Bearbeitet durch User
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.
Habt Ihr Ideen, wie ich das ganze noch eingrenzen kann oder Stück für Stück den möglichen Fehlerraum verringern kann?
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.
Angehängte Dateien:
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!
Da wundert mich, dass es in machen Fällen ging. Aber sowas passiert halt manchmal.
ich hätte mal die MakeFile posten sollen ...
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
Der atmega16a hat den SPI interrupt auf Vector 14, der atmega16 hat ihn auf 10
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.
:
Bearbeitet durch User
> Sagt wer? Na ich ... war aber Quatsch, muss mich verguckt haben. In beiden Datenblättern steht "Program Address": $014 Danke für's Richtig-stellen. > ATmega16 = SPI_STC_vect. > ATmega16A = SPISTC_vect. is aber gemein, dass es hier nicht auch so steht: https://www.microchip.com/webdoc/AVRLibcReferenceManual/group__avr__interrupts.html und hier auch nicht: https://www.nongnu.org/avr-libc/user-manual/group__avr__interrupts.html in beiden Links steht: ATmega16 = SPI_STC_vect ATmega16A = SPI_STC_vect Wo hast Du Deine Info her?
Hi
>Wo hast Du Deine Info her?
Ganz einfach: Datenblatt!
MfG Spess
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.