Forum: Mikrocontroller und Digitale Elektronik Seltsames SPI-Verhalten Atmega328P

Wenn der Schaltplan so gezeichnet ist wie der Aufbau, Resetbeschaltung 
spendieren, Abblockkondensatoren einlöten und bei größeren 
Temperaturschwankungen lieber einen externen Taktgeber verwenden, die 
sind in der Regel deutlich präziser.

Sebastian W. schrieb:
> PS: PB2 (!SS) ist nach bestem Wissen und Gewissen als Output
> konfiguriert, da er als !CS für das MCP2515-Modul benutzt wird.

Der Knackpunkt ist, ist das auch vor dem SPI-Init erfolgt!

Peter D. schrieb:
> Der Knackpunkt ist, ist das auch vor dem SPI-Init erfolgt!

Guter Punkt! Da könnte der Hase im Pfeffer liegen!

LG, Sebastian

Sebastian W. schrieb:
> Da könnte der Hase im Pfeffer liegen!

Wieso? SPI-Init konfiguriert sich stets nur und alles was es braucht...

Peter D. schrieb:
> er Knackpunkt ist, ist das auch vor dem SPI-Init erfolgt!

Das wars! Mille grazie, Peter. YMMD!

Manchmal sieht man den Wald vor lauter Bäumen nicht.

LG, Sebastian

Das ist merkwürdig!

Sebastian W. schrieb:
> Ein rudimentärer Nachbau auf dem Arbeitstisch mit einem Arduino Pro Mini
> funktioniert mit derselben Softwareversion tadellos, siehe Bild
> t5_garage01_st7735_ok.png. Beim Aufbau in der Werkstatt fehlt aber SPI
> 0x36 (und die entsprechende Übertragungszeit), siehe Bild
> t5_garage01_st7735_pl.png.

War bei dem "Arbeitstischaufbau" das MCP2515-Modul nicht angeschlossen?

Holger L. schrieb:
> War bei dem "Arbeitstischaufbau" das MCP2515-Modul nicht angeschlossen?

Nein, auch nicht. Das Problem war, dass ich SPI.begin() vor der 
MCP2515-Initialisierung aufgerufen habe, aber nicht auch vor der 
ST7735-Initialisierung, und dass die ST7735-Initialisierung vor der 
MCP2515-Initialisierung stattfand. PB2 war also während der 
ST7735-Initialisierung (obwohl dafür nicht benutzt) als Input 
konfiguriert, und der in der Werkstatt schwankende Eingangspegel an der 
"Antenne" PB2, also !SS, hat dann sporadisch die SPI-Maschinerie des 
Atmega in den Slave-Modus versetzt ...

LG, Sebastian

Sebastian W. schrieb:
> Peter D. schrieb:
>> er Knackpunkt ist, ist das auch vor dem SPI-Init erfolgt!
>
> Das wars! Mille grazie, Peter. YMMD!
> Manchmal sieht man den Wald vor lauter Bäumen nicht.

Leider zu früh gefreut. Es hat zwar so kurz funktioniert aber jetzt ist 
der Fehler trotz der Softwarekorrektur wieder da!

Ich habe in der Prozedur setRotation jetzt ein Portgewackel auf PD4 
eingebaut:

1

template <class I> void InterfaceST7735<I>::setRotation(uint8_t rotation)

2

{

3

    uint8_t ram_mode;

4

    if ( (rotation ^ m_rotation) & 0x01 )

5

    {

6

        m_base.swapDimensions();

7

        lcduint_t temp = m_offset_x;

8

        m_offset_x = m_offset_y;

9

        m_offset_y = temp;

10

    }

11

    m_rotation = (rotation & 0x03);

12

    this->start();

13

    PORTD |= (1<<PORTD4);

14

    setDataMode(0);

15

    PORTD &= ~(1<<PORTD4);

16

    this->send(0x28);

17

    PORTD |= (1<<PORTD4);

18

    this->send(0x36);

19

    PORTD &= ~(1<<PORTD4);

20

    setDataMode(1);

21

    PORTD |= (1<<PORTD4);

22

    switch ( m_rotation )

23

    {

24

        case 0: // 0 degree CW

25

            ram_mode = 0b00000000;

26

            break;

27

        case 1: // 90 degree CW

28

            ram_mode = 0b01100000;

29

            break;

30

        case 2: // 180 degree CW

31

            ram_mode = 0b11000000;

32

            break;

33

        default: // 270 degree CW

34

            ram_mode = 0b10100000;

35

            break;

36

    }

37

    this->send(ram_mode | m_rgb_bit);

38

    PORTD &= ~(1<<PORTD4);

39

    setDataMode(0);

40

    PORTD |= (1<<PORTD4);

41

    this->send(0x29);

42

    PORTD &= ~(1<<PORTD4);

43

    this->stop();

44

}

Und dann habe ich sowohl das CAN-Modul als auch das Display abgezogen 
und die Software laufen lassen ohne dass irgendetwas an den SPI-Ports 
angeschlossen ist. Das Ergebnis siehe Bild: Es wird jetzt 0x28 statt 
0x36 gesendet!

Was mir auffällt ist das DEBUG L->H geht obwohl das erste Byte 0x28 
immer noch gesendet wird ...

LG, Sebastian

OMG schrieb:

Also zunächst mal danke für die Rückmeldung. Allerdings:

OMG schrieb:
> - einen soliden Aufbau wählen.
Der Aufbau mit Streifenraster ist sehr solide.

OMG schrieb:
> - genügend Abblock-Kondensatoren vorsehen (laut Schaltplan
>   fehlen am AVR alle Kondensatoren!)
Jetzt nachgerüstet. Wie zu erwarten war (zum Zeitpunkt des Fehlers 
benötigte der uC nur Strom für winzigste interne Gateumladungen) keine 
Änderung.

OMG schrieb:
> - alle fliegenden Leitungen beseitigen da diese beliebig
>   Störungen auffangen können.
Fliegende Leitungen habe ich keine (Zuleitungen wohl).

OMG schrieb:
> Wenn ich "Lüftungssteuerung "
>   lese dann ist das allein schon ein Grund für Fehlfunktion.
> So wie das jetzt aufgebaut ist kann das nicht gutgehen.
Ist halt eine induktive Last.

Mir ist allerdings bei der Beantwortung deines Beitrags aufgefallen, das 
das Gate des IRLML6244 keinen Pulldown hat und also während der 
Initialisierung floatet, und auch noch einen 12k zu GND nachgerüstet.

Ich habe jetzt alle Leitungen nach außen (ausser der 15V-Zuleitung) 
gekappt. Der Fehler tritt immer noch auf!

Weitere Infos folgen ...

LG, Sebastian

Liebe Leute,

ich habe höchstwahrscheinlich die Ursache für mein Problem gefunden.

Sebastian W. schrieb:
> Es scheint als ob beim Werkstattaufbau beim Aufruf von transfer(0x36)
> SPIF schon gesetzt wäre. Allerdings sollte das Lesen von SPDR beim
> vorherigen Aufruf von transfer(0x28) SPIF gelöscht haben.

Sebastian W. schrieb:
> Was mir auffällt ist das DEBUG L->H geht obwohl das erste Byte 0x28
> immer noch gesendet wird ...

Werkstattaufbau und Arbeitstischnachbau unterscheiden sich in einem 
wesentlichen Punkt: Während der Arduino Pro Mini auf dem Arbeitstisch 
den Arduino-Bootloader enthält ist beim Werkstattaufbau ein 
selbstgebauter CAN-Bootloader im Einsatz. Dieser CAN-Bootloader endet 
mit dem Senden einer ACK-Nachricht an den CAN-Bootserver. Dabei mache 
ich im CAN-Bootloader den Fehler am Ende SPDR nicht mehr zu lesen und 
also SPIF gesetzt zu lassen. Und es scheint so zu sein, dass danach SPCR 
= SPSR = 0 vor dem Sprung vom Bootloader zur Applikation zwar SPI 
deaktiviert, SPIF aber gesetzt bleibt!

Dann startet die Applikation, aktiviert SPI wieder und beginnt das 
Display zu initialisieren. SPDR wird geschrieben aber SPIF ist noch 
gesetzt. Also endet das anschliessende Warten auf SPIF sofort. Wird dann 
SPDR gelesen dann wird SPIF zwar gelöscht, aber man liest das bei einer 
vorherigen Übertragung erhaltene Byte. Sobald dann die aktuelle 
Übertragung fertig ist wird SPIF wieder gesetzt. Und dieser Zustand kann 
dann recht lange anhalten.

Wenn in diesem Zustand dann aber SPDR geschrieben wird während die 
frühere Übertragung noch läuft (gegen das es in diesem Zustand ja keine 
Absicherung mehr gibt) dann gibt es eine race condition bei der 
anscheinend entweder die neue Übertragung verfällt oder das vorherige 
Byte erneut gesendet oder auch ein ganz anderes Byte gesendet wird

Ich habe jetzt provisorisch folgenden Code in die Lüftungssoftware 
eingebaut und das Problem wird umgangen:

1

#ifdef CANBOOT_WORKAROUND

2

  // The following is to work around an issue of the canboot bootloader ...

3

  SPI.begin();

4

  uint8_t spif = !!(SPSR & _BV(SPIF));

5

  if (spif) {

6

    uint8_t spi = 0xFF;

7

    if (SPSR & _BV(SPIF)) spi = SPDR;

8

    TraceVar(spi);

9

    spif = !!(SPSR & _BV(SPIF));

10

    TraceVar(spif);

11

  }

12

  SPI.end();

13

#endif

Später werde ich den CAN-Bootloader korrigieren und installieren. 
Hoffentlich funktioniert mein Mechanismus, bei dem der CAN-Bootloader 
sich selbst überschreibt! Ansonsten müsste ich bei allen Geräten lokal 
an die ISP-Stecker und das wäre doch ziemlicher Aufwand ...

LG, Sebastian

S. Landolt schrieb:
> Das nun verstehe ich nicht - weshalb reicht als Notbehelf nicht ein
> simples 'wirfmichweg = SPDR;' zu Beginn der Anwendungssoftware?

Sollte auch reichen. Ich brauche aber die Rückmeldung (über TraceVar auf 
TXD0) ob SPIF tatsächlich gesetzt ist um meine spätere Korrektur des 
CAN-Bootloaders zu verifizieren. Ausserdem hatte ich die Befürchtung, 
wirfmichweg würde wegoptimiert. Die zweite Abfrage von SPIF innerhalb 
der if-Anweisung ist aber in der Tat völlig überflüssig ...

LG, Sebastian.

S. Landolt schrieb:
>> Befürchtung, wirfmichweg würde wegoptimiert
>
> Okay - in meinem Assembler wird nichts wegoptimiert, und in C gibt es
> doch sicher eine Möglichkeit, eine solche Variable festzunageln
> (volatile?), oder?

Das sollte gehen. Allerdings habe ich grad noch mal das Datenblatt 
gelesen, und dort steht: "Alternatively, the SPIF bit is cleared by 
first reading the SPI Status Register with SPIF set, then accessing the
SPI Data Register (SPDR)". Insofern ist es wohl sicherer, vor dem Lesen 
von SPDR auch noch SPSR zu lesen ...

LG, Sebastian

Sebastian W. schrieb:
> Ausserdem hatte ich die Befürchtung,
> wirfmichweg würde wegoptimiert.

Wird es auch. Macht aber nix, der Lesezugriff auf SPDR wird nicht 
wegoptimiert. Ziel erreicht, kein Speicher verschwendet.

"volatile" ist am SPDR schon gesetzt, das reicht.

1

 uint8_t wirfmichweg=SPDR;

2

 SPDR;

3

 (void)SPDR;

Kompiliert zu:

1

        in r24,0x2e

2

        in r24,0x2e

3

        in r24,0x2e

Ich bevorzuge die letzte Variante, da ist klar dokumentiert, dass der 
gelesene Wert verworfen werden soll.

Sebastian W. schrieb:
> Später werde ich den CAN-Bootloader korrigieren und installieren.
> Hoffentlich funktioniert mein Mechanismus, bei dem der CAN-Bootloader
> sich selbst überschreibt!

Ok, der Bootloader ist korrigiert und installiert, und der 
CANBOOT_WORKAROUND ist nicht mehr nötig, SPIF ist beim Einsprung in die 
Anwendung jetzt 0.

Im Bootloader waren zwei Fehler. Zum einen wurde beim Senden nach dem 
Warten auf SPIF nie SPDR gelesen und so SPIF gelöscht. Das erklärt mir 
auch einige vorher unerklärliche Fehler bei der Installation neuer 
Anwendungssoftware mit dem Bootloader, weil dadurch genau die oben 
beschriebenen Sendefehler auftreten können. Zum anderen habe ich vor dem 
Sprung zur Anwendung erst die Ports auf Input ohne Pullup zurückgesetzt 
und danach SPI über SPCR abgeschaltet, und dadurch wohl den SPI Slave 
Modus aktiviert und so SPIF gesetzt!

In diesem Zusammenhang habe ich auch noch herausgefunden das allein das 
Lesen von SPDR nicht ausreicht um SPIF zu löschen; wie im Datenblatt 
erwähnt muss zuvor erst noch SPSR gelesen werden.

LG, Sebastian

Es ist good practice in jeder Initfunktion, das Interface zurück zu 
setzen. Dazu das Interface disablen und alle Interruptflags durch 
1-setzen (beim AVR) zu löschen.