VN9D5D20FN frequently setting SPI error bit in global status byte, datasheet not clear on cause

[Dazai]

I am controlling a VN9D5D20FN high side driver with the SPI2 interface on an STM32F373.  I can communicate with the high side driver, and sometimes briefly get an output to turn on using SPI control.  However, frequently the high side driver sets the SPI Error bit in the global status byte, mask 0x20.

I cannot determine why the high side driver is reporting a SPI error, and the datasheet is not clear on what causes that bit to be set (or at least I haven't been able to find it).  The datasheet is here: https://www.st.com/resource/en/datasheet/vn9d5d20fn.pdf

On page 23, it states:

"The SPIE is a logical OR combination of errors related to a wrong SPI communication (SCK
count and SDI stuck at errors).

The SPIE bit is automatically set when SDI is stuck at High or Low.

The SPIE is automatically cleared by a valid SPI communication."

So, it appears SPIE gets set if SDI is stuck High or Low, or there are not enough SCK counts when receiving (24 bits per SPI transaction).  From logic analyzer traces, the SCK count is 24, so my guess is the driver is detecting SDI stuck High or Low, but I cannot find a description of how the high side driver determines a stuck at condition.

Here's one of the logic analyzer traces. I am trying to get the high side driver into Normal mode from Fail Safe, which from the datasheet (page 10) is done by writing the CTRL register (address 0x14) first with 0x4000, then 0x0800.  Here are those messages in the logic analyzer trace:

As can be seen from the global status byte returned on MISO in the second message, either that message or the one previously caused the high side driver to set the SPIE bit, but why?

Is it because MOSI (SDI) is low for a long period between messages, even though the CSN signal is not asserted between command messages?

Should those two messages be sent without de-asserting CSN in between?

Is the STM32F373 not releasing MOSI so it returns to high state in between transactions due to the configured pullup?

Any help is appreciated.

This is how I configure the STM32F373's SPI2 port (this is old code that uses the standard peripheral library and unfortunately I cannot migrate it to HAL/LL). PD3 and PD4 (MISO/MOSI respectively) have pullups, and PD7 (SCK) has a pulldown.  SCK is about 140 KHz as can be seen in the logic analyzer trace above. I am using interrupts to send 3 bytes since the STM32F373 does not support 24-bit SPI.

GPIO_InitTypeDef GPIO_InitStructure;
SPI_InitTypeDef SPI_InitStructure;
NVIC_InitTypeDef NVIC_InitStructure;

RCC_APB1PeriphClockCmd(RCC_APB1Periph_SPI2, ENABLE);
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOD, ENABLE);

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_DOWN;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_7;
GPIO_Init(GPIOD, &GPIO_InitStructure);

GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF;
GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
GPIO_InitStructure.GPIO_PuPd  = GPIO_PuPd_UP;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_4 | GPIO_Pin_3;
GPIO_Init(GPIOD, &GPIO_InitStructure);

GPIO_PinAFConfig(GPIOD, GPIO_PinSource7, GPIO_AF_5); // PD7: SPI2_SCK
GPIO_PinAFConfig(GPIOD, GPIO_PinSource4, GPIO_AF_5); // PD4: SPI2_MOSI
GPIO_PinAFConfig(GPIOD, GPIO_PinSource3, GPIO_AF_5); // PD3: SPI2_MISO

SPI_InitStructure.SPI_Direction = SPI_Direction_2Lines_FullDuplex;
SPI_InitStructure.SPI_Mode = SPI_Mode_Master;
SPI_InitStructure.SPI_DataSize = SPI_DataSize_8b;
SPI_InitStructure.SPI_CPOL = SPI_CPOL_Low;
SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge;
SPI_InitStructure.SPI_NSS = SPI_NSS_Soft;
SPI_InitStructure.SPI_BaudRatePrescaler = SPI_BaudRatePrescaler_256;
SPI_InitStructure.SPI_FirstBit = SPI_FirstBit_MSB;
SPI_InitStructure.SPI_CRCPolynomial = 7;

SPI_RxFIFOThresholdConfig(SPI2, SPI_RxFIFOThreshold_QF);

/* Initialize SPI2 */
SPI_Init(SPI2, &SPI_InitStructure);

EDIT: I just realized this code enables SPI2 during initialization and never disables it.  Does SPI2 need to be disabled between messages in order for it to release MOSI?

[Dazai · Accepted solution]

I figured this out, in case anyone else ends up here.  The SPI2 phase was set incorrectly so the VN9D5D20 would sometimes communicate for a bit but eventually error.  The problem was this line:

SPI_InitStructure.SPI_CPHA = SPI_CPHA_2Edge;

That sets the SPI CPHA to 1, and the VN9D5D20 needs CPHA set to 0, which is the SPI_CPHA_1Edge define.