How can I get SPI NSS pin driven high, and why is SPI transactions sometimes garbled?

1. NSS output in hardware mode is disappointment for all users. You have to manipulate it "manually", set it as GPIO and drive it low and high before and after transmission as needed. (When setting SSM, NSS pin is simply not connected to the SPI peripheral anymore, not as input nor as output).
2. I don't know, but loss of debugging might indicate some major hardware failure - some short, clock loss, surge in power. Is there anything external connected to the board?

JW

I am also getting the feeling NSS is not working as documented, but surely this should be fixed (either hardware or documentation)? It clearly states that SSI drives NSS when in software mode.

I've parked that for the moment, and changed my code to use a GPIO to drive NSS. I've gone to bare basics with the code below. It crashes 100% reliably on the line that writes to the data register (line 41 below). I can see in the debugger that the instructions following that is not executed (even though the debugger thinks it is - I am instruction stepping and registers are not loaded correctly). My experience with behaviour like that is that a critical exception was triggered (hardware fault) and that the debugger lost synch with the CPU. How can writing to the SPI DR cause such a severe error?

I have absolutely nothing but the USB cable connected to my board.

void DrvSPI_STM32L4::init()
{
 SPI1->CR2 = // SPI_CR2_LDMATX | // DMA Num TX Bytes is even.
 // SPI_CR2_LDMARX | // DMA Num RX Bytes is even.
 SPI_CR2_FRXTH | // RXNE event is generated if the FIFO level is > 1/4 (8-bit).
 (0b0111 << SPI_CR2_DS_Pos) | // 8-bit data transfer size.
 // SPI_CR2_TXEIE | // Disable TXE interrupt.
 // SPI_CR2_RXNEIE | // Disable RXNE interrupt.
 // SPI_CR2_ERRIE | // Disable Error interrupt.
 // SPI_CR2_FRF | // Motorola frame format.
 // SPI_CR2_NSSP | // No NSS pulses (asserted before transfer, and de-asserted after).
 SPI_CR2_SSOE | // SS output enabled in master mode (multimaster not supported).
 // SPI_CR2_TXDMAEN | // Disable TX DMA.
 // SPI_CR2_RXDMAEN | // Disable RX DMA.
 0;
 
 SPI1->CR1 = // SPI_CR1_BIDIMODE | // 2-line unidirectional data mode.
 // SPI_CR1_BIDIOE | // Not used if in 2-line unidirectional mode.
 // SPI_CR1_CRCEN | // CRC calculation disabled.
 // SPI_CR1_CRCNEXT | // Only used if CRC is enabled.
 // SPI_CR1_CRCL | // Only used if CRC is enabled.
 // SPI_CR1_RXONLY | // Full-duplex mode.
 SPI_CR1_SSM | // Software slave management.
 SPI_CR1_SSI | // NSS (CS) pin is high. (Not used if SSM is zero).
 // SPI_CR1_LSBFIRST | // MSB transferred first.
 SPI_CR1_SPE | // Enable SPI.
 (0b001 << SPI_CR1_BR_Pos) | // Baud = f_PCLK/4.
 SPI_CR1_MSTR | // Master configuration.
 // SPI_CR1_CPOL | // Clock Polarity select (see datasheet).
 // SPI_CR1_CPHA | // Clock Phase select (see datasheet).
 0;
 
 volatile uint8_t go = 0;
 while (go == 0) {}
 
 volatile uint8_t dummy;
 volatile uint8_t* byteDR = (volatile uint8_t*)&SPI1->DR;
 for(;;)
 {
 GPIOA->ODR &= ~(1 << 4); // Take CS low.
 *byteDR = 0x01; // Command.
 while ((SPI1->SR & SPI_SR_BSY) != 0) {} // Wait until not busy.
 GPIOA->ODR |= (1 << 4); // Take CS high;
 }
}

> It clearly states that SSI drives NSS when in software mode.

I'm not going to look up the exact wording and I know the manuals are not written very clearly, but the intention of that sentence is to say that the *internal* NSS node of the SPI module (after being disconnected from the pin by setting SSM) is connected to the register bit SSI.

The garbled

> STM32433

STM32L433?

What board is this? Is this a "known good" board such as Nucleo or Disco? What is the clocking? Can you try it with the reset setting of clocks, if it's not already the case?

Is there any other manipulation with SPI register before the above code is called? Are there any interrupts enabled in NVIC?

JW

> I found that when I run my code, instead of stepping through it, then I do not get the error.

Do you observe SPI registers in debugger? This may be intrusive, although I don't quite understand how would that result in the described behaviour, but then I am no wizard too.

So if yes, try to switch off any "live update" or close the registers windows and step through in that way.

IAR? Keil? Eclipsoid?

JW

PS. Have no experience with the SMPS. Can you please observe the supply pins while stepping through in the "failing" configuration?

JW