STM32H743 SPI Topic is solved

[fvantienen]

With the spi_v2 driver using DMA in SPI4 I get some weird extra pulse in the clock signal while using spiExchange.

Code: Select all

#define STM32_SPI_SPI4_RX_DMA_STREAM        STM32_DMA_STREAM_ID(2, 3)
#define STM32_SPI_SPI4_TX_DMA_STREAM        STM32_DMA_STREAM_ID(2, 4)

SPIConfig spi_cfg = {
    false, // no circular buffer
#if defined(HAL_LLD_SELECT_SPI_V2)
    false, // no slave mode
    NULL, // no callback
#endif
    NULL, // no callback
    spi_resolve_slave_port(t->slave_idx),
    spi_resolve_slave_pin(t->slave_idx),
    SPI_CFG1_DSIZE_VALUE(7) | SPI_CFG1_MBR_VALUE(3),
    SPI_CFG2_CPHA | SPI_CFG2_CPOL,
}

spiStart(..., &spi_cfg);
spiSelect(...);
spiExchange(...); // Done with non-cached memory in first 64k of ram0 (0x24000000)
spiUnselect(...);


I'm not sure where this might be coming from. The transfer of 2 bytes is correct, but somehow there is long wait after that and an extra clock pulse. Does someone have an idea or a way to debug this more easily?

[fvantienen]

First transfer using spi V1

Second (and later) transfer using spi V1

Based on my above tests I think that the problem for V1 is inside the spiStart as it is generating a spike before the CS. This might give an indication for V2 as well. I hope anyone here has an idea how to solve this issue?

[Giovanni]

Hi,

Which ChibiOS version are you using? there were recent changes on SPIs.

The glitch could be caused when enabling/disabling the SPI peripheral.

Outside the CS it is harmless, within CS it should be harmless because CS would reset the slave afterward but not nice anyway.

The long time could be explained by IRQ servicing after the exchange is over, it could be happening because something done in the ISR, you may try to toggle a GPIO inside the ISR and understand exactly what is triggering that.

Will try to replicate over next weekend but I never saw this on my LA.

Giovanni

[fvantienen]

Ok I figured out where the clock pulse is generated and it is in:

Code: Select all

spip->spi->CR1 &= ~SPI_CR1_SPE;

I haven't really looked into the SPI manuals from STM32. But doesn't this have to do with the SPI_CFG2_CPOL? Similarly the MOSI also generates a spike, but that is before the CS, so less of a problem.

I removed that line totally and the driver still works and doesn't generate an extra clock pulse at the end. But it generates it likes the first driver before instead.

[fvantienen]

Another weird thing I noticed is that when I do SPI transactions using non-cached memory, I still sometimes get incorrect memory.

Code: Select all

#define STM32_NOCACHE_ENABLE                TRUE
#define STM32_NOCACHE_MPU_REGION            MPU_REGION_6
#define STM32_NOCACHE_RBAR                  0x24000000U
#define STM32_NOCACHE_RASR                  MPU_RASR_SIZE_64K
....
memcpy(i->dma_buf_out, (void *)t->output_buf, (size_t)t->output_length);
spiExchange((SPIDriver *)p->reg_addr, t_length, i->dma_buf_out, i->dma_buf_in);
memcpy((void *)t->input_buf, i->dma_buf_in, (size_t)t->input_length);


* Above the dma_buf_... are in non-cached memory and output_buf and input_buf are in normal memory.

I copy back and forth from this non-cached memory, but sometimes this goes wrong and it read/sends the incorrect old data. If I invalidate the dma buffers with cacheBufferInvalidate before/after the spi exchange it works fine. Is there maybe a reason what could explain this weird behaviour, or am I understanding the caching incorrectly?

[Giovanni]

Hi,

It is possible something is cached before setting up the MPU, I am not sure of the expected behavior in this case. Try doing a cache clear and invalidate just after calling halInit() and see if the anomaly is still there (I would add this internally to the HAL if this is the case). Probably this will not fix it.

Are you sure your buffers are in the uncached region? inspect the pointers passed to the spiExchange() function. I suspect those buffers are not really uncached for some reason. Check also the map file and verify addresses.

Giovanni

[fvantienen]

I will try to verify that caching problem and see if I set up everything correctly with your suggestions.

Currently ran into some other problem with the SPI V2 driver. Somehow it didn't work with SPID1 and if I debugged correctly I think each SPI transaction is just timing out without an interrupt. When I change back to V1 everything works fine. What is actually changed between V1 and V2?

[Giovanni]

Hi,

Not much has changed actually in the code, you may do a compare, V1 is still present, you may also revert to V1 if you wish.

Giovanni

[fvantienen]

Ok figured out sort of why it wasn't working. It all has to do with

Code: Select all

SPI_CR1_SPE

. If you set it at then end of spi_lld_configure it works (this is done in v1 as well). Not sure why or what is wrong exactly, but this might give you some ideas and/or solutions.

[Giovanni]

Hi,

SPE is set before operations and reset on operation end, I found a problem with "polled exchage", enabling SPE is missing there, are you using this functionality?

Moving in bug reports since this is a bug already.

Giovanni