SMT32G0xx SPI peripheral clock missing in simplex DMA transmit

[Chris_Mr]

I have found that in the STM32G070 (so likely all STM32G0?) that the SPI misses the first clock if:

a) The CPOL is 1 and CPHA is 1

b) The DMA is used to transmit

When sending 0x07 as the first byte the data on the actual output is 0x0e.  The second byte followed the first intact.  I didn't test it with the top bit of the second byte set to see if it was 0x0f that was sent.

When CPOL and CPHA are both zero the data / clocking is correct.

The STM32F4 it was connected to doesn't have this feature.

[waclawek.jan]

Observe the SPI signals using oscilloscope/logic analyzer.

STM32 serves as master or as slave?

JW

[Chris_Mr]

Yes, I did use an oscilloscope (counted the clocks by hand), all the data that followed, just out by one bit compared to the first clock.

The STM32G070 was the master (as I mentioned in the OP title it was in simplex mode).

[waclawek.jan]

I still don't quite understand what are you doing, but try to set the SCK pin's drive to a higher value in its GPIO_OSPEEDR.

JW

[Chris_Mr]

I don't need to change the driver strength, as I already said..

"When CPOL and CPHA are both zero the data / clocking is correct."

This is at 32Mb/s.

In other words, with CPHA and CPOL at 1 the clock idles high, then the second transition (clock going back high) is the one the data is clocked in on at the far end, the data changes when the clock goes low.  It does all that, but misses out the first clock so all the data is one bit out.

The SPI on the STM32F4 it is connected to transmits it properly, and the G0 receives it properly, just not the other way round.  The G0 misses the first bit.. but only when CPOL and CPHA are 1.

[Chris_Mr]

I just tried it on a STM32G031-Nucleo and that one works fine.  I tried both SPI1 and 2 - the original problem was on SPI2 of the G070.  If I get time I will put the original back and take a picture.

One of the differences is that the original has all the DMA channels running at the same time whereas what I just tried was with one DMA.

I'll be back!

[KnarfB]

When SPI is not yet enabled (SPE==0) the output pins are High-Z. The pin reading will be random and depend on internal /external pull-up/pull-down. This may affect how a slave/scope sees the transfer. See 27.5.8 in RM0454 Rev 5.

hth

KnarfB

[Chris_Mr]

If the G0 is different to say the F4 (predecessor) shouldn't that be in the errata?  The F4 works fine.

Same section says "For handling DMA, follow the dedicated section."

From a user perspective one has to ask.. so which is it, the DMA section or the "special case"?

[KnarfB]

> shouldn't that be in the errata?

No, errata are no release notes. And, this is by design to support multi-master scenarios.

F4 shows the same behavior. You can easily test it by wobbling the SPI pins with their internal pull-up/down like so:

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_USART2_UART_Init();
  MX_SPI2_Init();
  /* USER CODE BEGIN 2 */


  for(;;) {
	  MODIFY_REG(GPIOB->PUPDR, GPIO_PUPDR_PUPD10, GPIO_PULLUP<<GPIO_PUPDR_PUPD10_Pos);
	  MODIFY_REG(GPIOB->PUPDR, GPIO_PUPDR_PUPD15, GPIO_PULLUP<<GPIO_PUPDR_PUPD15_Pos);
	  HAL_Delay(10);
	  MODIFY_REG(GPIOB->PUPDR, GPIO_PUPDR_PUPD10, GPIO_PULLDOWN<<GPIO_PUPDR_PUPD10_Pos);
	  MODIFY_REG(GPIOB->PUPDR, GPIO_PUPDR_PUPD15, GPIO_PULLDOWN<<GPIO_PUPDR_PUPD15_Pos);
	  HAL_Delay(10);
  }
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
	  static uint8_t buffer[2] = {0x07, 0xFF};
	  HAL_SPI_Transmit_DMA(&hspi2, buffer, sizeof(buffer));
	  HAL_Delay(100);
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }

and watching the waveforms (while loop never reached).

hth

KnarfB

[Chris_Mr]

Surely a for(;;) loop will never finish so the above code will never get to the DMA section - but that's because of the code, rather than the SPI peripheral.  Also, it won't be running at 32Mb/s - the pullup / down would be too weak to generate a clock at 32Mb/s (certainly with a scope probe attached!).

In the above original issue the SCK pins at both ends were set to be pullup.. continuously.. not wobbled.  One set to send simplex, then the other.  Both set to CPOL and CPHA 1 so the idle condition with both SPIs disabled is 1 on the SCK line.  The F4 sends the data correctly the G0 omits the first clock pulse.. just the first clock pulse.

I am on holiday until the middle of next week when I will reply with more information.