cancel
Showing results for 
Search instead for 
Did you mean: 

SPI GPIOs don't work (except SCK) using DMA

simo zz
Senior II

Hi, 

I am using an STM32H7RSxx device and I need to use the SPI6 (both full and half duplex) with the DMA.

The problem I am facing on is the MOSI pin doesn't transmit anything.Only the SCK is working.

Despite having configured it for SPI6 Alternate Function (according to datasheet)

simozz_0-1751471885253.png

  // SPI6 pins
  // SCLK, MISO, MISO, NSS
  GPIO_InitStruct.Pin = LL_GPIO_PIN_4 | LL_GPIO_PIN_5 | LL_GPIO_PIN_6 | LL_GPIO_PIN_7;
  GPIO_InitStruct.Mode = LL_GPIO_MODE_ALTERNATE;
  GPIO_InitStruct.Speed = LL_GPIO_SPEED_FREQ_VERY_HIGH;
  GPIO_InitStruct.OutputType = LL_GPIO_OUTPUT_PUSHPULL;
  GPIO_InitStruct.Pull = LL_GPIO_PULL_UP;
  GPIO_InitStruct.Alternate = LL_GPIO_AF_8;
  LL_GPIO_Init(GPIOA, &GPIO_InitStruct);

it always stays to low level.

What is strange is the fact that if I use PB5 as SPI6 MOSI 

simozz_1-1751471952301.png

I can see as the pin stays at high level in idle state, but low for the rest of transmission, and this is quiet confusing.

If I am not blind at all, the TRM and datasheet does not say anything about it..

Of course the DMA transmission buffer is not zero.

I have read on another post that the order of initialization can matter, but honestly, I could not figure out the solution.

I attached a small working example of what I am doing, I hope I will receive some hint.

Thanks,

s.

 

12 REPLIES 12

Does MOSI transmit something non-zero if you use a blocking SPI call? HAL_SPI_TransmitReceive?

 

> SCB_InvalidateDCache_by_Addr(&dmaTxBuff, DMA_TXRX_BUFF_SIZE);
> SpiDmaTrf((uint32_t) &dmaTxBuff, (uint32_t) &dmaRxBuff);

If data cache is disabled, why are you calling invalidate here? If it was enabled, you should be calling clean, not invalidate.

 

Your buffers aren't aligned to a cache page, so using cache is not an option here.

 

Still think this is a cache issue.

If you feel a post has answered your question, please click "Accept as Solution".

EDIT.

@TDK it is a mistake. 

I will try with HAL functions.

s.

I finally think I found the final solution to this issue, which seems to be related also with the port allocation of the DMA:  concretely, choosing the PORT #1 (#0 doesn't work) as follows:

  LL_DMA_SetLinkAllocatedPort(p_dma, p_channel, LL_DMA_LINK_ALLOCATED_PORT1);
  LL_DMA_SetSrcAllocatedPort(p_dma, p_channel, LL_DMA_LINK_ALLOCATED_PORT1);
  LL_DMA_SetDestAllocatedPort(p_dma, p_channel, LL_DMA_LINK_ALLOCATED_PORT1);

Thanks @TDK for your time, your suggestions about cache handling have been very useful.

s.