Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

[ARM] STM32F4 SPI NSS (CS) not functioning as expected

Status
Not open for further replies.

mr_monster

Member level 4
Joined
May 10, 2012
Messages
79
Helped
0
Reputation
0
Reaction score
0
Trophy points
1,286
Activity points
1,964
I've setup SPI3, together with the rest of the project, in CubeMX. The CS is controlled by software so before starting a transfer I pull the pin low using a command from the GPIO library, after that a number of bytes are clocked out using a function from the SPI library and finally CS is pulled up again. What I've seen on the logic analyzer shows that when I send data over SPI a few times consecutively the CS will get pulled high only after the last transfer which is not what I want and not how the code is written. Any idea what could be wrong?
 

GPIOs can be expected to do exactly what you are writing to it. So if the observed logic waveform are different from your imtention, check the code.
 

Here is my code:

Code:
void MAX5216Init(SPI_HandleTypeDef *hspi)
{
	MAX5216_CS_HIGH;  // De-select MAX5216
        MAX5216_CLR_HIGH; // Normal operation
	
	uint8_t aTxBuffer[]={0x80,0,0}; // Temp buffer for command
	
	MAX5216_CS_LOW;
	HAL_SPI_Transmit(hspi,(uint8_t*)aTxBuffer,3,1000);
	MAX5216_CS_HIGH;
}

void MAX5216Write(SPI_HandleTypeDef *hspi, uint16_t value)
{
	uint8_t aTxBuffer[]={0,0,0}; // Temp buffer for MAX5216 data
	
	aTxBuffer[0]=((uint8_t)(value>>10))|0x40;
	aTxBuffer[1]=(uint8_t)(value>>2);
	aTxBuffer[2]=(uint8_t)(value<<6);
	
	MAX5216_CS_LOW;
	HAL_SPI_Transmit(hspi,(uint8_t*)aTxBuffer,3,1000);
	MAX5216_CS_HIGH;
}

Pins are defined as such:

Code:
  /*Configure GPIO pin : PD4 CS */
  GPIO_InitStruct.Pin = GPIO_PIN_4;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
  HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

  /*Configure GPIO pin : PD7 CLR */
  GPIO_InitStruct.Pin = GPIO_PIN_7;
  GPIO_InitStruct.Mode = GPIO_MODE_OUTPUT_OD;
  GPIO_InitStruct.Pull = GPIO_PULLUP;
  GPIO_InitStruct.Speed = GPIO_SPEED_HIGH;
  HAL_GPIO_Init(GPIOD, &GPIO_InitStruct);

And the macros:
Code:
#define MAX5216_CS_LOW   HAL_GPIO_WritePin(MAX5216_PORT,MAX5216_CS_PIN,GPIO_PIN_RESET)
#define MAX5216_CS_HIGH  HAL_GPIO_WritePin(MAX5216_PORT,MAX5216_CS_PIN,GPIO_PIN_SET)
#define MAX5216_CLR_LOW  HAL_GPIO_WritePin(MAX5216_PORT,MAX5216_CLR_PIN,GPIO_PIN_RESET)
#define MAX5216_CLR_HIGH HAL_GPIO_WritePin(MAX5216_PORT,MAX5216_CLR_PIN,GPIO_PIN_SET)
 

You don't show the code that performs multiple SPI transactions.

As far as I understand, you are configuring the CS pin as open drain with pull-up, so rising edges will be rather slow. That's no the suggested operation of a SPI CS pin and could well explain the observed problem. Use regular push-pull mode instead.
 
Here is how the functions are being called in main:
Code:
MAX5216Init(&hspi3);
MAX5216Write(&hspi3,32000);

I have changed the settings to push/pull & no pull-up.
Here is what I see now:
Capture.JPG
 

CS looks OK. Sent data seems to correspond to the code.
 

CS seems OK other than that weird behavior at the beginning. I'm pulling the pin high in code, after that it will go low and than it will toggle high-low again before sending data. I am also not sure why the clock is not returning high after the the 3rd byte was sent.
 

The claimed "weird behaviour" obviously happens before the execution of the shown code starts, so I can't comment it. I would expect that it's reflecting some of your code. But as the SPI is not clocked, it has no impact at the slave side.

You are using the ARM SPI hardware interface, so the bus timing is commanded by your interface setup. The diagram seems to show SPI mode 0 with low idle state of SCK. Everything looks like normal operation.
 

Everything does seem OK now, the logic analyzer is unhappy about one of the transfers but I can confirm the ADC which is getting the data works as should. Do you happen to know which document has all this info that might help me avoid these problems in the future? I have the peripheral guide and the reference manual but both do not go into any sort of details.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top