STM32H755ZI SPI / Behaviour of MOSI after disabling peripheral

[DSchl.1]

Hi everyone

I'm currently working with the STM32H755ZI SPI1 peripheral. I'm using low level driver to read 2 bytes of data. It works fine. I'm transmitting 2 dummy data bytes (0xFF) in order to get some response from the SPI slaves. However, I'm wondering about the behaviour of the MOSI signal after the transfer has been finished. I have attached a screenshot, the MOSI is the light blue / cyan signal (SCK is yellow, CS is green, and MISO is purple). Why is the signal cycled low and then high after I've finished the transfer? What could cause this behaviour? I assume the peripheral manages the state of the MOSI signal...

Parameters are as shown below:

Baudrate = LL_SPI_BAUDRATEPRESCALER_DIV256 (clock is 180MHz)

BitOrder = LL_SPI_MSB_FIRST

CRCCalculation = LL_SPI_CRCCALCULATION_DISABLE

CRCPoly = CRCPOLY 0x00

ClockPhase = LL_SPI_PHASE_1EDGE

ClockPolarity = LL_SPI_POLARITY_LOW

DataWidth = LL_SPI_DATAWIDTH_8BIT

Mode = LL_SPI_MODE_MASTER

NSS = LL_SPI_NSS_HARD_OUTPUT

TransferDirection = LL_SPI_FULL_DUPLEX

I'm also setting the following parameters:

• LL_SPI_PROTOCOL_MOTOROLA
• LL_SPI_NSS_POLARITY_HIGH
• Enable NSS Pulse Management
• Enable GPIO Control

After initialization, I'm trying to read 2 bytes of data. I'm using the following procedure:

• Start the transfer size (with requested number of bytes)
• Enable the SPI peripheral and start master transfer
• Wait for TXP, send first dummy data byte (0xFF)
• Wait for TXP, send second dummy data byte (0xFF) and read first data byte if FIFO packing level is > 0
• Read second data byte if FIFO packing level is > 0
• Wait until EOT
• Clear EOT and TXTF flags
• Suspend master transfer and disable SPI peripheral

Any explanation would be greatly appreciated.

Regards

Daniel.

[berendi]

While the software is waiting for the end of transfer, the SPI peripheral is starting to transmit another byte. Since the transmit FIFO is empty, it has to resort to the action defined by the UDRCFG bits in SPI->CFG1. By default, SPI_CFG1_UDRCFG is "00: slave sends a constant pattern defined by the user at SPI_UDRDR register" which is 0 unless you explicitly set some value.

[DSchl.1]

Thanks for the reply. I've tried to set

LL_SPI_SetUDRPattern to 0xFFF etc...

and also with or without

LL_SPI_SetUDRPattern to LL_SPI_UDR_DETECT_END_DATA_FRAME

Still the same behaviour... I'm a bit confused about the "slave sends a constant pattern..." I'm currently the master and have no actual slaves, just some shift registers to write and read... Is there a way to control the behaviour of the MOSI signal?

edit: meant to say "shift registers to write" of course.. this particular problem is about the output of data (even though i'm also reading data over the SPI1).

[DSchl.1]

Just to clarify my last post/reply... I'm transmitting two dummy bytes (cyan - MOSI) and expecting two bytes of data to read from the shift register (magenta - MISO). But I'm wondering about the behaviour of the cyan signal. The hint with the UDR pattern didn't work for me, I was not able to control the behaviour of the MOSI signal...

[DSchl.1]

The question still remains: I don't know what causes the MOSI to toggle after the SPI peripheral has been disabled. It was not the underrun...

[waclawek.jan]

Post a minimal but complete compilable example exhibiting the problem.

JW

[TDK]

Nothing here violates the SPI protocol. Cycling low/high doesn't actually send data since SCK is idle. I'd not spend too much time on it unless it's actually a problem. MOSI doesn't know what to do once it has sent all data.

[DSchl.1]

That's actually a bit of a problem, as the concerned code is part of a big "framework" still under development. I've posted the relevant code snippet in this link: https://community.st.com/s/question/0D53W000002h4xiSAA/stm32h755zi-spi-proper-way-to-receive-data?t=1585144796375

I admit that this is far away from "complete compilable", however I was just hoping for a simple answer to my question. As TDK states below, since the SCK is idle, there's no data sent, so this shouldn't pose a problem.

[DSchl.1]

Agreed, It's not really a problem, I was just wondering about the behaviour. If it's just not defined, I can live with it.. Thanks anyway.