SPI funktioniert nicht auf ATtiny441

Ich raube mir schon seit einiger Zeit die Haare darüber. Ich versuche nur, eine grundlegende SPI-Transaktion durchzuführen – ein Byte zu senden – auf dem ATtiny441 , aber ich bekomme nichts auf den SCK- und MOSI-Leitungen. Zuerst sind hier meine Sicherungseinstellungen und Pinbelegung (in Rot): Die wahrscheinlich nützlichste Information hier ist, dass ich den internen 8-MHz-Oszillator verwende und nicht durch 8 teile. Beachten Sie, dass ich die SPI-Pins neu zuordne, damit ich kann Lassen Sie meinen Logikanalysator eingeschaltet, während Sie mit den Standardpins programmieren.Erweiterte Sicherungsbits Hohe Sicherungsbits Niedrige Sicherungsbits Pinbelegung

Hier ist meine main.cDatei:

#define F_CPU 8000000UL

#include <avr/io.h>
#include <util/delay.h>

#define SCK         3
#define MOSI        1
#define CSN         2

uint8_t data = 0;
uint8_t reg = 0;


int main(void)
{
    PRR = 0; // turn off power reduction
    REMAP |= (1<<SPIMAP); // remap SPI pins
    // set SCK, MOSI, CSN as outputs:
    DDRA = (1<<SCK) | (1<<MOSI) | (1<<CSN); 
    // enable SPI, set as master, use f_clkIO/16 (500kHz):
    SPCR = (1<<SPE) | (1<<MSTR) | (1<<SPR0);
    reg = SPSR;
    reg = SPDR;

    while(1)
    {
        PORTA &= ~(1 << CSN); // clear CSN
        SPDR = data++; // send byte
        while( !(SPSR & (1<<SPIF)) ); // wait for flag to set
        PORTA |= (1 << CSN); // set CSN
        _delay_ms(10);
    }

    return 0;
}

Ich lese die SPSRund SPDRregistriert vor der whileSchleife auf Empfehlung von Atmels AVR151 App Note (Seite 11).

Wenn ich den Code ausführe, bleibt die CSNZeile niedrig, zusammen mit SCKund MOSI, was darauf hindeutet, dass sie in dem while( !(SPSR & (1<<SPIF)) );Abschnitt hängen bleibt, der darauf wartet, dass SPIFgesetzt wird. Wenn ich diese Zeile auskommentiere, CSNgeht die Zeile für ~ 25 us auf Low und dann wieder auf High, was erwartet wird. Ich habe auch versucht, die Ausgänge manuell hoch zu setzen , um sicherzustellen, dass es sich nicht um ein Pin-Verbindungsproblem handelt, und sie haben gut funktioniert SCK.MOSI

Frage: Sieht jemand den Fehler in meinen Wegen? Ich habe das Gefühl, dass irgendwo ein kleiner, dummer Fehler ist.

Bearbeiten: Ich möchte auch erwähnen, dass ich es mit und ohne gesetztem Taktteiler (durch 8) Sicherungsbit und mit und ohne Neuzuordnung der SPI-Pins von der Standardposition versucht habe (dh Programmieren, Programmierleitungen entfernen, Logiksondenleitungen anbringen) .

Leider sehe ich keinen offensichtlichen Fehler in Ihrem Code. Aber ein Vorschlag zum Testen: Überprüfen Sie, ob das SPI-Modul aktiviert ist und die Pins überhaupt übernimmt - entweder ein anderer SPI-Modus mit hohem Leerlauftakt oder ein Pin auf High, bevor Sie SPI aktivieren, und prüfen Sie, ob es abfällt. Das Überprüfen von kompiliertem Code ist auch eine gute Idee (er ist kurz genug, um ihn "von Hand" zu zerlegen und zu überprüfen), vielleicht eine seltsame / fehlerhafte Optimierung oder ein Fehler in Ihren Headern zum Beispiel? Übrigens. Ich nehme an, Sie sehen keine Aktivität in den Daten- und clk-Zeilen, auch nicht, wenn die Zeile auskommentiert ist, oder?
@Martin Das hatte ich befürchtet, aber danke für die guten Tipps zur Fehlerbehebung! Die werde ich auf jeden Fall ausprobieren. Und das ist richtig – es gibt keine Aktivität auf SCK oder MOSI mit dieser whileauskommentierten Zeile.
@Martin Hab es kapiert! Schauen Sie sich meine Antwort an, wenn Sie interessiert sind. Danke noch einmal!

Antworten (1)

Eureka! Es stellt sich heraus, dass das SPIMAPBit falsch zugeordnet ist!

/usr/local/CrossPack-AVR-20131216/avr/include/avr/iotn441.h:377:0: note: this is the
location of the previous definition
 #define SPIMAP 0
 ^

(Es sollte Bit 1 sein.) Daher schlug die Zeilenneuzuordnung der SPI-Pins fehl! Dies wird korrigiert, indem ein #define SPIMAP 1in den #defineAbschnitt eingefügt wird.

BEARBEITEN: Wie Martin betonte, verwende ich tatsächlich eine alte Version von avr-libc. Ich habe die neueste Version von CrossPack verwendet , die heute fast 4 Jahre alt ist. Die neueste Version hat diesen Fehler behoben.

Gut, dass du es gelöst hast. Nur zu Ihrer Information, dieser Fehler scheint in (mindestens) neueren Bibliotheken von Atmel nicht vorhanden zu sein, nämlich Version 3.6.0 von Ende 2016 ist in Ordnung ( distribution.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/ … ). Die Datumszeichenfolge in dieser Ausgabe, die Sie hier kopiert haben, ist sowieso etwas seltsam, da laut dem Änderungsprotokoll von Atmel die Unterstützung für ATtiny441 erst 2016 hinzugefügt wurde Insekt ...?