SPI MISO erkennt falsche Werte bei höherer Geschwindigkeit

[spi (Gast)]

Hallo,

ich kommuniziere per SPI zwischen einem STM und einem Atmel. Der Atmel 
ist hier der Master und würde laut Datenblatt einen SPI-Takt bis zu 
66MHz schaffen. Die Daten werden bei steigender Flanke am clock 
übernommen.

STM: STM32F105RC; core-clock = 72MHz

Atmel: AT32UC3A0512
www.atmel.com/Images/doc32058.pdf
core-clock = 66MHz


Nun ist es in meinem Fall so, dass meine Kommunikation nur bis ca. 20MHz 
funktioniert. Bei höheren Frequenzen „empfängt“ der Atmel nur noch 
falsche Werte. In die andere Richtung ist es allerdings so, dass der STM 
(=slave) immer das richtige empfängt.

Ich konnte mal ein Screenshot vom Oszi machen. Hier legt der Slave den 
Wert 0x34 bei einem Takt von 22MHz auf die MISO-Leitung. Der Atmel 
glaubt in diesem Fall jedoch ein 0x1E erkenne zu müssen. So wie ich das 
sehe, sollten die MISO-Werte aber zur richtigen Zeit anliegen und ich 
verstehe gar nicht, wie der Atmel hier auf 0x1E kommt.

Hat jemand einen Tipp wie ich bei der Fehlersuche weiter vorgehen 
sollte?

Zum Oszi: Es hat eine Auflösung von 500MHz bzw. 2,5GS/s

[spi (Gast)]

Nochmal das Bild im Anhang...

[Blitzbirne (Gast)]

Was soll das denn für ein Dateutyp im Anhang sein?

[Blitzbirne (Gast)]

Deine Hilfslinien sind aber alle bei einem unterschiedlichen 
Spannungspegel auf CLK eingezeichnet.
Wenn ich die roten Linien alle etwas nach links verschiebe komme ich auf 
0x1E.

[spi (Gast)]

natürlich noch der Code (ich verwende Atmels Framework ASF und 
freeRTOS):

void spiInit(void)
{
    spiInitPins();
    spiInitModule();
    spiDmaInit();
}


void spiInitModule(void)
{
    struct spi_device spi_dev_conf_cam1 = {
        .id = SPI_CS_CAM1 };

    spi_master_init(&AVR32_SPI1);
    spi_master_setup_device(&AVR32_SPI1, &spi_dev_conf_cam1, SPI_MODE_0, \
            22000000, 1);
    spi_enable(&AVR32_SPI1);
}

void spiDmaInit(void)
{
    /* PDCA channel options */
    static const pdca_channel_options_t PDCA_OPTIONS_FOR_TRANSFER =
    {
        .addr   = NULL,                     // memory address
        .pid    = AVR32_PDCA_PID_SPI1_TX,   // select peripheral/SPI tx channel
        .size   = 0,                        // transfer counter
        .r_addr = NULL,                     // next memory address
        .r_size = 0,                        // next transfer counter
        .transfer_size = PDCA_TRANSFER_SIZE_BYTE// select size of the transfer
    };
    static const pdca_channel_options_t PDCA_OPTIONS_FOR_RECIEVE =
    {
        .addr   = NULL,                     // memory address
        .pid    = AVR32_PDCA_PID_SPI1_RX,   // select peripheral/SPI rx channel
        .size   = 0,                        // transfer counter
        .r_addr = NULL,                     // next memory address
        .r_size = 0,                        // next transfer counter
        .transfer_size = PDCA_TRANSFER_SIZE_BYTE// select size of the transfer
    };

    /* Disable all interrupts */
    Disable_global_interrupt();

    INTC_register_interrupt( (__int_handler) &pdca_int_handler, \
            AVR32_PDCA_IRQ_0, AVR32_INTC_INT0);
    INTC_register_interrupt( (__int_handler) &pdca_int_handler, \
            AVR32_PDCA_IRQ_1, AVR32_INTC_INT1);

    /* First disable all interrupts */
    SENSOR_SPI->idr = 0xFFFF;

    /* Enable SPI interrupt */
    SENSOR_SPI->IER.nssr = 1;

    /* Init PDCA channel with the pdca_options */
    pdca_init_channel(SPI1_PDCA_CHANNEL_TX, &PDCA_OPTIONS_FOR_TRANSFER);
    pdca_init_channel(SPI1_PDCA_CHANNEL_RX, &PDCA_OPTIONS_FOR_RECIEVE);

    /* Enable all interrupts */
    Enable_global_interrupt();

    /* Enable now the transfer */
    pdca_enable(SPI1_PDCA_CHANNEL_RX);
    pdca_enable(SPI1_PDCA_CHANNEL_TX);
}

uint8_t spiRWCam1(uint8_t dataTx)
{
    uint16_t dataRx = 0;
    // select SPI chip.
    spi_selectChip(SENSOR_SPI, SPI_CS_CAM1);
    // Send the Status Register Read command.
    spi_write(SENSOR_SPI, (uint16_t)dataTx);
    // Unselect SPI chip.
    spi_unselectChip(SENSOR_SPI, SPI_CS_CAM1);

    spi_read(SENSOR_SPI, &dataRx);
    return (uint8_t)dataRx;
}

[spi (Gast)]

Blitzbirne schrieb:
> Deine Hilfslinien sind aber alle bei einem unterschiedlichen
> Spannungspegel auf CLK eingezeichnet.
> Wenn ich die roten Linien alle etwas nach links verschiebe komme ich auf
> 0x1E.

Hmmm... ich fand es auch schwierig die tatsächlich richtige Position der 
Linien zu bestimmen, da ich ja nicht weiß wann der Master der Meinung 
ist die Daten übernehmen zu müssen. Ich finde auch, dass die Flanken 
recht unregelmäßig ausschauen.

Das mit dem nach links verschieben ist schon mal ein super Hinweis. 
Danke schön (auch wenn ich noch nicht weiß was ich nun ändern könnte).

[spi (Gast)]

Die Funktion mit der ich die Daten per DMA in einen Puffer einlese habe 
ich noch vergessen:

void spiRBuffCam(volatile uint8_t *buffAddr, uint32_t sizeOfBuff)
{
    spi_selectChip(&AVR32_SPI1, SPI_CS_CAM1);

    portENTER_CRITICAL();
    {
        pdca_enable_interrupt_transfer_complete(SPI1_PDCA_CHANNEL_RX);
        /* load PDCA */
        pdca_load_channel( SPI1_PDCA_CHANNEL_RX, (void *)buffAddr, sizeOfBuff);
        /* enable the PDCA Rx channel first then the Tx channel */
        pdca_enable(SPI1_PDCA_CHANNEL_RX);
        /* send dummy data from the user page in flash */
        pdca_load_channel(SPI1_PDCA_CHANNEL_TX, (void *)dummy_0xff_filledBlockAtFlash, sizeOfBuff);
        //pdca_enable(SPI1_PDCA_CHANNEL_TX);    //already enabled at init
   }
   portEXIT_CRITICAL();
}

Ich stelle allerdings gerade (leider erst jetzt) fest, dass ich mit der 
Funktion spiRWCam1() die Daten sogar bei 30MHz auslesen kann. Mein 
Problem ist dann also nur dann, wenn ich per DMA auslesen möchte. (also 
mit der Funktion: spiRBuffCam())

[(prx) A. K. (prx)]

STM32 Reference: SPI Slave Frequency <= PCLK/2. Mehr als 36MHz sind also 
sowieso nicht drin. Bei den SPIs am APB1 mit halbem PCLK <= 18MHz.

Wie sieht die Kabelei aus? Versorgungsspannung? SPI Pinmode vom STM32?

[(prx) A. K. (prx)]

spi schrieb:
> Nochmal das Bild im Anhang...

Bei Frequenzen in diesem Bereich solltest du auf die Massekabel der 
Tastköpfe verzichten und mit Massefeder an der Tastkopfspitze arbeiten:
https://www.mikrocontroller.net/attachment/27280/groundspring.png

Mit Massekabel kann ein steilflankiges 20MHz Rechteck auf dem Oszi 
nämlich auch so aussehen: 
https://www.mikrocontroller.net/attachment/27258/74AC-Ausgang.PNG
wobei man da nicht das Signal misst, sondern Artefakte im Tastkopf.

[spi (Gast)]

A. K. schrieb:
> Massefeder an der Tastkopfspitze

Was es alles gibt... Hardware und Messtechnik sind leider nicht meine 
Stärke. Habe auch ein wenig gebraucht um zu kapieren wo/wie die 
Massefeder an den Tastkopf angeschlossen werden soll. Hier mal ein Bild, 
falls sich jemand anderes mal die gleiche Frage stellen sollte:
http://images.vogel.de/vogelonline/bdb/464000/464042/25.jpg

Neue Messungen sind zur Zeit leider nicht möglich, da ich kein eigenes 
Oszi besitze.


A. K. schrieb:
> Mehr als 36MHz sind also sowieso nicht drin.

Ja, 36MHz wären mein Ziel.

Mittlerweile habe ich herausgefunden, dass schon ein delay von einem 
einzigen Takt zwischen den einzelnen Bytes ausreicht um die Übertragung 
mit 32MHz laufen zu lassen. Atmel bietet diese Möglichkeit netter weise 
per Konfiguration der Schnittstelle an:

//! Default Config Spi Master Delay BCT ( delay between consecutive transfers)
#define CONFIG_SPI_MASTER_DELAY_BCT            1

A. K. schrieb:
> Wie sieht die Kabelei aus? Versorgungsspannung? SPI Pinmode vom STM32?

/* ___ SPI1 configuration ________________________________________________*/
SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Slave;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low;
SPI_InitStructure.SPI_CPHA = SPI_CPHA_1Edge;
SPI_InitStructure.SPI_NSS = SPI_NSS_Hard;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_8;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;
SPI_Init(SPI1, &SPI_InitStructure);

Das mit der Kabelei könnte vielleicht wirklich der Grund sein, warum ich 
noch nicht ganz auf die 36MHz komme. Ich habe mal versucht den Aufbau 
meiner beiden Platinen/MCU's auf einer Skizze darzustellen.

[Mike (Gast)]

spi schrieb:
> Nochmal das Bild im Anhang...

Bei solchen Signale kann man die Fehler gut verstehen. Grundsätzlich ist 
SPI eine digitale Signalübertragung und so sollten die Signale dann auch 
aussehen, bevor man erwarten kann, dass die Gegenstelle die richtig 
empfangen kann. Entweder liegt das an der Messtechnik oder die Signale 
sind tatsächlich so unsauber. Bevor die nicht ordentlich sind, ist da 
ohne Signalregenerierung nicht mehr zu erwarten.

[Wolfgang (Gast)]

spi schrieb:
> Zum Oszi: Es hat eine Auflösung von 500MHz bzw. 2,5GS/s

Was du da angibst, ist vermutlich die Analogbandbreite und die 
Abtastfrequenz.

Hast du einen 1:10 Tastkopf verwendet?

Welche Impedanz und Länge hat dein Kabel?
Wie sehen Treiberimpedanz und Empfängerimpedanz/Leitungsabschluß aus?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

spi schrieb:
> Ich konnte mal ein Screenshot vom Oszi machen.
Da sieht es für mich so aus, wie wenn sich die Daten annähernd 
gleichzeitig mit den steigenden Taktflanken, die an sich auch nur 
rudimentär und nach Erklärung sichtbar sind! Das wäre dann aber der 
falsche Zeitpunkt zur Abtastung. Besser wäre hier die fallende Flanke. 
Verwendest du den falschen SPI Modus?

BTW: Wenn das Signal am uC-Pin wirklich so aussieht, dann gibt das nie 
eine sichere Übertragung.

[Schreiberling (Gast)]

Hallo,


Bedenke auch, dass die Kabellaufzeit eine Rolle spielt. Bei 50MHz sind 
deine Zeitreserven sehr gering (10ns): die Taktflanke muss zum ST hin 
und die Datenflanke zum ATMEL zurück - bei 6ns/m geht das schon 
theoretisch nur bis weniger als 1m.
Praktisch eher noch weniger, weil der ST auch noch Zeit braucht, seine 
Daten zu setzen. Probleme können also schon früher auftreten, z.B. bei 
20cm.
Schau dir mal die Setup und Holdzeiten im Datenblatt an und rechne dein 
Timing mal durch - mit Kabellaufzeit.

Der ST hat dagegen nie ein Problem: der bekommt Takt und Daten 
gleichzeitig.

Abhilfe: Frequenz runter, Kabel kürzer oder asynchrone Kommunikation.

[(prx) A. K. (prx)]

spi schrieb:
> Das mit der Kabelei könnte vielleicht wirklich der Grund sein,

Die Länge der Kabel ist extrem wichtig, wenn du sie nicht passend mit 
Treiber versehen und abgeschlossen hast. Jenseitig einiger zig cm ist 
das nötig und angesichts RJ45 gehe ich davon aus, dass du weit jenseits 
davon liegst. Siehe Wellenwiderstand.

Auf die Laufzeitfrage wurde ja schon hingewiesen. Mögliche Lösung wären 
2 SPI-Master. Einer für AVR32=>STM32 und einer andersrum, jeweils 
unidirektional betrieben. Dann treten keine Laufzeiteffekte auf. 
Blöderweise gibts beim STM32 wohl nur ein SPI mit 36MHz, die anderen nur 
mit 18MHz.

Oder Ethernet.

> [c]/* _ SPI1 configuration

Sorry, ich meinte die GPIO Pinkonfiguration der SPI-Pins. Die 
Grenzfrequenz der STM32 Pins hängt davon ab - und von der Höhe der 
Versorgungsspannung. Daher die Frage.