Skip to content

NUCLEO-H743ZI2 SPI.transfer(data, SPI_CONTINUE) deasserts the SS pin #1303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
pierremolinaro opened this issue Feb 14, 2021 · 2 comments
Closed
Assignees

Comments

@pierremolinaro
Copy link

On the NUCLEO-H743ZI2 board, the SPI_CONTINUE parameter of the SPI.transfer, SPI.transfer16 functions seems without any effect: the SS pin is always put HIGH after the transfer. Here is a sample sketch, that uses the SPI3, but I think there is the same bug for all 6 SPI. I use STM32Duino 1.9.0.

#include <SPI.h>

static const uint8_t SPI3_MOSI = PC12 ;
static const uint8_t SPI3_MISO = PC11 ;
static const uint8_t SPI3_SSEL  = PA15 ;
static const uint8_t SPI3_SCLK = PC10 ;

void setup() {
  SPI.setMOSI (SPI3_MOSI) ;
  SPI.setMISO (SPI3_MISO) ;
  SPI.setSCLK (SPI3_SCLK) ;
  SPI.setSSEL (SPI3_SSEL) ;
  SPI.begin () ;
}

void loop () {
  delay (100) ;
  SPI.beginTransaction (SPISettings (1000 * 1000, MSBFIRST, SPI_MODE0)) ;
  SPI.transfer (0x12, SPI_CONTINUE) ;
  SPI.transfer (0x34, SPI_CONTINUE) ;
  SPI.transfer16 (0x5678, SPI_CONTINUE) ;
  SPI.transfer16 (0xABCD, SPI_LAST) ;
  SPI.endTransaction () ;
}

The following logic analyser screen capture shows the bug. A workaround to use only one data block SPI.transfer per transaction.
stm32duino-h743-bug

Best regards,

Pierre Molinaro

@ABOSTM
Copy link
Contributor

ABOSTM commented Feb 16, 2021

Hi @pierremolinaro,
The management of Slave Selection (SS or ChipSelect) is a bit complex and there is a misuse of API:
Some explanation are available here in the wiki:
https://github.com/stm32duino/wiki/wiki/API#spi

I know it is a bit confusing, but when SS pin is defined either in constructor, or using API setSCLK() this will implicitly determine Hardware management of SS pin. And it means it is not possible to use SPI_CONTINUE because pin is managed by hardware (software control is not possible).

In order to control SS by SPI library software, with ability to use SPI_CONTINUE, you should not use setSCLK() and instead provide SS pin at each later API:

void setup() {
  SPI.setMOSI (SPI3_MOSI) ;
  SPI.setMISO (SPI3_MISO) ;
  SPI.setSCLK (SPI3_SCLK) ;
//  SPI.setSSEL (SPI3_SSEL) ;

  SPI.begin (SPI3_SSEL) ;
}

void loop () {
  delay (100) ;
  SPI.beginTransaction (SPI3_SSEL, SPISettings (1000 * 1000, MSBFIRST, SPI_MODE0)) ;
  SPI.transfer (SPI3_SSEL, 0x12, SPI_CONTINUE) ;
  SPI.transfer (SPI3_SSEL, 0x34, SPI_CONTINUE) ;
  SPI.transfer16 (SPI3_SSEL, 0x5678, SPI_CONTINUE) ;
  SPI.transfer16 (SPI3_SSEL, 0xABCD, SPI_LAST) ;
  SPI.endTransaction (SPI3_SSEL) ;
} 

Note: just for information there is an open issue on SPI on STM32H743: #1294
You may face the same, and it impact SS signal:

  • When SS is managed by hardware, signal will raise almost at the same time as truncated clock fall.
  • When SS is managed by software, it is even worse, SS signal raise early during last clock pulse.

@pierremolinaro
Copy link
Author

pierremolinaro commented Feb 17, 2021 via email

@ABOSTM ABOSTM closed this as completed Feb 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants