Konfigurieren Sie den SPI-Slave, um Daten zu verarbeiten, die zur falschen Zeit kommen

Ich experimentiere mit dem SPI-Protokoll (schnelle Geschwindigkeiten, bei denen 5 Bytes Daten in etwas weniger als 500 us übertragen werden) auf dem STM32F410, der als SPI-Vollduplex-Slave konfiguriert ist. Ein Master-Gerät sendet ein Befehlsbyte an den STM32F4 und der STM32F4 antwortet mit 4 Bestätigungsbytes, gefolgt von einer Routine, die bei etwa 1,3 ms (gemessen durch die DWT-Taktzykluszählung) ausgeführt wird. Es wird erwartet, dass diese 5-Byte-Datenübertragung etwa 25 bis 27 Mal pro Sekunde stattfindet.

Ich stelle fest, dass das Master-Gerät manchmal genau dieselben Daten nacheinander in einer Zeitspanne von 90 us senden kann (der STM32F4-Slave sollte damit rechnen, dass er abwechselnd Daten über SPI in einer Zeitspanne von mindestens 4 ms dazwischen empfängt). Ich habe Screenshots des Logikanalysators angehängt, die dieses Vorkommen zeigen:

Das erste empfangene 0x42-Byte ist zu erwarten, und der STM32F4-Slave hat mit den entsprechenden Bytes geantwortet (beachten Sie, dass das zweite 0x42 danach nicht mehr vorhanden sein sollte):

Das zweite empfangene 0x42-Byte sollte nicht aufgetreten sein (Master-Gerät kann in diesem Szenario nicht konfiguriert/programmiert werden):

Nach dem obigen Vorfall konnte der STM32F4-Slave nie wieder richtig auf das Master-Gerät antworten (die an den Master zurückgesendeten Bestätigungsbytes sind immer 0x99 – das ist das im SPI-Interrupt-Sendepuffer konfigurierte Byte):

In dieser Situation habe ich versucht, den Funktionsaufruf zu entfernen __AppliSendBuff(), der einem HF-Transceiver befiehlt, Daten zu übertragen, und wenn das ungewöhnliche Ereignis eintritt, kann der STM32F4-Slave immer noch korrekt auf den Master antworten.

Meine Frage ist : Wie könnte ich die SPI-Daten ignorieren, die zu unerwarteten Zeiten vom Master kommen? Warum führt eine fehlgeschlagene SPI-Transaktion dazu, dass alle anderen zukünftigen SPI-Transaktionen fehlschlagen? Welche Vorsichtsmaßnahmen sollte ich treffen, wenn ich Code für den STM32F4-Slave schreibe?

Was ich versucht habe : Deaktivieren der SPI_CS GPIO-Interrupts, wenn der CS-Chip heruntergezogen wird, sodass die SPI-Transaktion mitten im gesamten Prozess nicht stattfindet, bis ich den SPI_CS GPIO-Interrupt wieder aktiviere. Vor dieser Änderung würde der STM32F4-Slave im zweiten empfangenen 0x42-Befehl nur 0x99 auf 0x42 und 0xFF antworten, die auf 0x42 folgen. Trotzdem schlagen alle anderen SPI-Transaktionen fehl und der Slave würde mit 0x99 antworten.

Mein STM32F4-Code :
Das Interrupt-Segment:

/*** STM32F4 INTERRUPT HANDLERS ***/

/* GPIO Interrupt Handler */
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) {
   if(GPIO_Pin == SPI2_CS_PIN) {
      /* Temporarily disable SPI2 CS interrupt */
      HAL_NVIC_DisableIRQ(EXTI1_IRQn);

      /* Generate interrupt flags when master device sends SPI data */
      /* dummybyte is a uint8_t array of size 1, with the element being 0x99 */
      HAL_SPI_TransmitReceive_IT(&hspi2, (uint8_t*)dummybyte, (uint8_t*)pSpi2RxBuff, cSpi2RxLen);
   }
   else if (...) {
      ...
   }
}

/* SPI Interrupt Handler */
void HAL_SPI_TxRxCpltCallback(SPI_HandleTypeDef *hspi) {
   if(hspi->Instance == SPI2) {
      if (...) {
         ...
      }
      else if(pSpi2RxBuff[0] == 0x41) {
         /* Activate 0x41 flag for further processing in main loop if 0x41 was received */
         xFlag_41 = SET;
      }
      else if(pSpi2RxBuff[0] == 0x42) {
         /* Activate 0x42 flag for further processing in main loop if 0x42 was received */
         xFlag_42 = SET;
      }
      else {
         /* Discard data by doing nothing */
      }
   }
}

Die Hauptschleife:

while (1) {
   if(xFlag_41 == SET) {
      /* Respond back to system with acknowledge bytes */
      HAL_SPI_TransmitReceive(&hspi2, (uint8_t*)pSend41Data, (uint8_t*)pTempRxBuff, cSpi2TxLen, SPI2_TIMEOUT);
      
      /* Commands RF Transceiver to transmit data respective to received command from master */
      __AppliSendBuff(&command41);

      xFlag_41 = RESET;

      /* Re-enable SPI2_CS interrupts. Note that priority was set in MX_GPIO_Init() */
      HAL_NVIC_EnableIRQ(EXTI1_IRQn);
   }
   else if(xFlag_42 == SET) {
      /* Respond back to system with acknowledge bytes */
      HAL_SPI_TransmitReceive(&hspi2, (uint8_t*)pSend42Data, (uint8_t*)pTempRxBuff, cSpi2TxLen, SPI2_TIMEOUT);
          
      /* Commands RF Transceiver to transmit data respective to received command from master */
      __AppliSendBuff(&command42);

      xFlag_42 = RESET;

      /* Re-enable SPI2_CS interrupts. Note that priority was set in MX_GPIO_Init() */
      HAL_NVIC_EnableIRQ(EXTI1_IRQn);
   }
}

Muss ich den SPI-Slave auch so konfigurieren, dass er 4 Dummy-Bytes sendet (vielleicht um die SPI-Datenregister zu leeren), falls ich ein Junk-/nicht registriertes Befehlsbyte erhalte?

Danke schön!

Update: Ich habe das Deaktivieren des CS-Line-Interrupt-Deaktivierens (das ein GPIO-Interrupt-Deaktivieren ist) ausgelassen und die Flag-Reset-Aktionen auf die erste Zeile in den Else-If-Blöcken verschoben, und es wurden einige Änderungen im Logikanalysator angezeigt (die erste richtige Sequenz war immer noch das gleiche):

Zweite falsche Reihenfolge:

0x41 genau nach der zweiten falschen Sequenz oben:

0x42 genau nach dem obigen 0x41 (falsche Bytes an den Master zurückgesendet):

Und alle danach ausgetauschten Bytes sind wie folgt (unabhängig von 0x41 oder 0x42):

Ich habe vergessen, die Interrupt-Prioritäten in den ursprünglichen Beitrag oben aufzunehmen:

/* SPI CS line has the highest interrupt priority */
HAL_NVIC_SetPriority(EXTI1_IRQn, 1, 0);
HAL_NVIC_EnableIRQ(EXTI1_IRQn);
/* SPI Peripheral connected to the master device */
HAL_NVIC_SetPriority(SPI2_IRQn, 1, 1);
HAL_NVIC_EnableIRQ(SPI2_IRQn);