STM32H743ZI Nucleo SPI1 mit HAL funktioniert nicht

[Dabidududuu (Gast)]

Ich probiere nun seit bestimmt 8h rum aber ich schaffe es nicht, SPI1 
auf einem Nucleo-144 mit STM32H743ZI zum laufen zu bekommen. Das ist die 
wesentliche Konfiguration:

__HAL_RCC_SPI1_CLK_ENABLE();
__HAL_RCC_I2C1_CLK_DISABLE();

__HAL_RCC_GPIOA_CLK_ENABLE();
__HAL_RCC_GPIOB_CLK_ENABLE();
__HAL_RCC_GPIOD_CLK_ENABLE();

RCC_PeriphCLKInitTypeDef PeriphClkInitStruct = {0};
PeriphClkInitStruct.PeriphClockSelection = RCC_PERIPHCLK_SPI1;
PeriphClkInitStruct.Spi123ClockSelection = RCC_SPI123CLKSOURCE_PLL;
if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInitStruct) != HAL_OK) {
  std::cout << "[Error] PeriphCLK failed!\r\n";
}

GPIO_InitTypeDef GPIO_InitStruct = {0};

GPIO_InitStruct.Pin = GPIO_PIN_5|GPIO_PIN_6;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF5_SPI1;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

GPIO_InitStruct.Pin = GPIO_PIN_5;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = GPIO_AF5_SPI1;
HAL_GPIO_Init(GPIOB, &GPIO_InitStruct);

/* Chip Select */
GPIO_InitStruct = {0};
GPIO_InitStruct.Pin = GPIO_PIN_14;
GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_LOW;
GPIO_InitStruct.Alternate = 0x0;
HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_SET);

spi_handle.Instance = SPI1;
spi_handle.Init.Mode = SPI_MODE_MASTER;
spi_handle.Init.Direction = SPI_DIRECTION_2LINES;
spi_handle.Init.DataSize = SPI_DATASIZE_8BIT;
spi_handle.Init.CLKPolarity = SPI_POLARITY_LOW;
spi_handle.Init.CLKPhase = SPI_PHASE_2EDGE;
spi_handle.Init.NSS = SPI_NSS_SOFT;
spi_handle.Init.BaudRatePrescaler = SPI_BAUDRATEPRESCALER_128;
spi_handle.Init.FirstBit = SPI_FIRSTBIT_MSB;
spi_handle.Init.TIMode = SPI_TIMODE_DISABLE;
spi_handle.Init.CRCCalculation = SPI_CRCCALCULATION_DISABLE;
spi_handle.Init.CRCPolynomial = 7;
spi_handle.Init.NSSPMode = SPI_NSS_PULSE_DISABLE;
spi_handle.Init.NSSPolarity = SPI_NSS_POLARITY_LOW;
spi_handle.Init.FifoThreshold = SPI_FIFO_THRESHOLD_01DATA;
spi_handle.Init.TxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
spi_handle.Init.RxCRCInitializationPattern = SPI_CRC_INITIALIZATION_ALL_ZERO_PATTERN;
spi_handle.Init.MasterSSIdleness = SPI_MASTER_SS_IDLENESS_00CYCLE;
spi_handle.Init.MasterInterDataIdleness = SPI_MASTER_INTERDATA_IDLENESS_00CYCLE;
spi_handle.Init.MasterReceiverAutoSusp = SPI_MASTER_RX_AUTOSUSP_DISABLE;
spi_handle.Init.MasterKeepIOState = SPI_MASTER_KEEP_IO_STATE_ENABLE;
spi_handle.Init.IOSwap = SPI_IO_SWAP_DISABLE;

const HAL_StatusTypeDef ret = HAL_SPI_Init(&spi_handle);

if(ret != HAL_OK) {
  std::cout << "[Error] HAL_SPI_Init failed!\r\n";
  exit(-1);
}

Nachdem man beim Googlen auf sehr viele Beiträge mit HAL-Problemen stößt 
frag ich mich, ob die Bibliothek überhaupt korrekt funktioniert. 
Allerdings konnte bisher kein Beitrag mein Problem lösen.

Das konkrete Problem ist, dass SCLK / CS zwar funktionieren aber MOSI 
immer auf 0 bleibt.

So läuft die Übertragung ab:

uint8_t opcodes[2];
opcodes[0] = 0b00100000;
opcodes[1] = 0b00000010;

uint8_t reg_content;

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_RESET);

HAL_SPI_Transmit(&this->spi_handle, opcodes, 2, 250);

while(HAL_SPI_GetState(&this->spi_handle) != HAL_SPI_STATE_READY);

HAL_SPI_Receive(&this->spi_handle, &reg_content, 1, 250);

while(HAL_SPI_GetState(&this->spi_handle) != HAL_SPI_STATE_READY);

HAL_GPIO_WritePin(GPIOD, GPIO_PIN_14, GPIO_PIN_SET);

return (reg_content >> 5);

Hab schon mit einem Durchgangsprüfer gecheckt, dass die Pins passen.
Konkret sieht es so aus:

PA5 <-> SCLK
PA6 <-> MISO
PB5 <-> MOSI
PD14 <-> CS

Über jeden Tipp bin ich sehr dankbar.

[Johannes S. (Gast)]

Dabidududuu schrieb:
> PeriphClkInitStruct.Spi123ClockSelection = RCC_SPI123CLKSOURCE_PLL;

und wie ist die PLL initialisiert? Mal Code mit CubeMX generiert? Für 
einfache Standardschnittstellen kann man dem generierten Code schon 
vertrauen.

[jo mei (Gast)]

Johannes S. schrieb:
> und wie ist die PLL initialisiert?

Das ist doch voll der Käse an der Taktkonfiguration zu suchen wenn
er berichtet:

Dabidududuu schrieb:
> Das konkrete Problem ist, dass SCLK / CS zwar funktionieren aber MOSI
> immer auf 0 bleibt.

Dann läuft die Takt-Maschinerie ja prinzipiell.

[Johannes S. (Gast)]

TL;DR. Aber sicher richtig, wird nicht am Takt liegen.
Auch die gezeigte Konfig sieht ok aus, dann ist der Hund eher wie so oft 
im nicht gezeigten Teil begraben.
Es wird ja offensichtlich mit C++ gemischt, da kann man auch diffizile 
Fehler einbauen. Lebt das Objekt mit dem spi_handle noch wenn es benutzt 
wird? Ist der Inhalt da noch gültig? Code mal mit dem define FULL_ASSERT 
übersetzt?

[jo mei (Gast)]

Johannes S. schrieb:
> Lebt das Objekt mit dem spi_handle noch wenn es benutzt
> wird?

Nachdem alles (Clock, MOSI, MISO, CS) von der Gültigkeit des
SPI-Handles abhängig ist und Teile davon funktionieren ist es
äusserst unwahrscheinlich dass "das Objekt mit dem spi_handle"
zerstört oder ungültig gemacht worden ist.

Aber: PB5 (soll ja MOSI sein) kommt zweimal als Pin vor.

Siehe UM1974

Seite 30 --> 6.12 Solder bridges
  und
Seite 66ff --> Table 20. NUCLEO-H743ZI pin assignments

Es könnte da ein Konfigurations- oder Verwechslungs-Problem
beim TO vorhanden sein.

[jo mei (Gast)]

Dabidududuu schrieb:
> Über jeden Tipp bin ich sehr dankbar.

Poste hier ein Minimal-Projekt mit dem man den Fehler nachvollziehen
kann. Ich habe 743ZI Nucleos zum Testen, könnte also ggf. helfen.

[Johannes S. (Gast)]

jo mei schrieb:
> Es könnte da ein Konfigurations- oder Verwechslungs-Problem
> beim TO vorhanden sein.

dagegen spricht:

Dabidududuu schrieb:
> Hab schon mit einem Durchgangsprüfer gecheckt, dass die Pins passen.
> Konkret sieht es so aus:
> PA5 <-> SCLK
> PA6 <-> MISO
> PB5 <-> MOSI
> PD14 <-> CS

zumindest wenn von der CPU aus gemessen wurde.

[jo mei (Gast)]

jo mei schrieb:
> Nachdem alles (Clock, MOSI, MISO, CS) von der Gültigkeit des
> SPI-Handles abhängig ist

Ok ich nehm einen Teil zurück ... der CS wird "soft" ausgeführt,
ist also nicht von der SPI Maschine abgeleitet.