-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
Hi @pierremolinaro, I know it is a bit confusing, but when SS pin is defined either in constructor, or using API In order to control SS by SPI library software, with ability to use
Note: just for information there is an open issue on SPI on STM32H743: #1294
|
Hello,
Thank you very much for your answer, I understand my mistake.
Best regards,
Pierre Molinaro
… Le 16 févr. 2021 à 17:49, Alexandre Bourdiol ***@***.***> a écrit :
Hi @pierremolinaro <https://github.com/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 <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 <#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.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1303 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEWKZVC2XKNTKBY5375F6MTS7KOYDANCNFSM4XTKEMJQ>.
|
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.
The following logic analyser screen capture shows the bug. A workaround to use only one data block SPI.transfer per transaction.

Best regards,
Pierre Molinaro
The text was updated successfully, but these errors were encountered: