Skip to content
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

Nucleo 32 G431KB: SPI not working as expected #2400

Closed
acunipisa opened this issue Jun 14, 2024 · 14 comments · Fixed by #2403
Closed

Nucleo 32 G431KB: SPI not working as expected #2400

acunipisa opened this issue Jun 14, 2024 · 14 comments · Fixed by #2403
Labels
bug 🐛 Something isn't working
Milestone

Comments

@acunipisa
Copy link

Describe the bug
Using a Nucleo 32 stm32g431kb for SPI communication. After removing SB4 jumper (to disconnect PB3, or D13, from SWO of the on board stlink), SPI is not working as expected using stmduino core.
No signal on SCK (D13, or PB3) can be observed using an o-scope. The same is true for MOSI (D11, or PB5).

To Reproduce
Nucleo32 gk431kb with SB4 jumper removed. Plug USB, and upload the code using Arduino IDE 2.3.2.

#include <SPI.h>

void setup() {

  SPI.begin(); 
  SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0)); 
  SPI.transfer(0x52); 

}

void loop() {

  delay(10);
  SPI.beginTransaction(SPISettings(10000000, MSBFIRST, SPI_MODE0));
  SPI.transfer(0x52); 

}

Expected behavior
Normally, I would expect the SPI lines to show signals according to the communication protocol.

Desktop (please complete the following information):

  • OS: Windows 10
  • Arduino IDE version: 2.3.2
  • STM32 core version: 2.6.0
  • Tools menu settings if not the default: default
  • Upload method: Mass Storage

Board (please complete the following information):

  • Name: Nucleo 32 G431KB
@fpistm
Copy link
Member

fpistm commented Jun 14, 2024

Hi @acunipisa
You didn't change the pins used for SPI instance.

See the wiki to know how do this.

@acunipisa
Copy link
Author

acunipisa commented Jun 14, 2024

I appreciate your support.

Indeed, I changed the pins using the following code, but still not signals on the lines. I am wondering if it has something to do with the JTAG interface.

#include "SPI.h"

void setup() {

  SPI.setMISO(PB4);
  SPI.setMOSI(PB5);
  SPI.setSCLK(PB3);

  SPI.begin(1);
}

void loop() {

  delay(10);
  SPI.transfer(0x52);

}

Edit:

I am also checking the schematic. PB3 is connected to D13. Maybe I am missing something else..

image

I attached the complete schematic as well.
Uploading mb1430-g431kbt6-a02_schematic_internal.pdf…

@fpistm
Copy link
Member

fpistm commented Jun 14, 2024

Why this:
SPI.begin(1);
it should be no argument. Which core version you used ?

@acunipisa
Copy link
Author

Using core 2.6.0. I may try to use the new one.
Without the "1" the code just freezes if I use the same code.

@fpistm
Copy link
Member

fpistm commented Jun 14, 2024

Even with 2.6.0 you should not use argument for begin and drive yourself the CS pin.

@acunipisa
Copy link
Author

Installed core 2.7.1.

Removed the "1". If I do not modify the pins, I can observe the signals on PA7 and PA5, as expected.

However, when I change the pins, the code gets stuck when I set PB3 as SPI CLK. If I do not, MOSI is correctly observed on PB5.

#include "SPI.h"


void setup() {

  SPI.setMISO(PB4);
  SPI.setMOSI(PB5);
  //SPI.setSCLK(PB3); // uncomment and the code gets stuck

  SPI.begin();
}

void loop() {

  delay(10);
  SPI.transfer(0x52);

}

@acunipisa
Copy link
Author

Installed core 2.7.1.

Removed the "1". If I do not modify the pins, I can observe the signals on PA7 and PA5, as expected.

However, when I change the pins, the code gets stuck when I set PB3 as SPI CLK. If I do not, MOSI is correctly observed on PB5.

#include "SPI.h"


void setup() {

  SPI.setMISO(PB4);
  SPI.setMOSI(PB5);
  //SPI.setSCLK(PB3); // uncomment and the code gets stuck

  SPI.begin();
}

void loop() {

  delay(10);
  SPI.transfer(0x52);

}

By the way, the SCLK cannot be routed to PB3, and I cannot understand why. From the stm32g431kb datasheet it should be possible (indeed the manual of the nucleo32 board and the layout suggest that as well). I will keep investigating.

@fpistm
Copy link
Member

fpistm commented Jun 14, 2024

I've made a test with a Nucleo G431RB as I do not have the KB (but similar) and it works:
image

Will try to find a KB but my gess is you damaged your board when removing the SB.

@acunipisa
Copy link
Author

acunipisa commented Jun 14, 2024

First, let me thank you for taking the time to test the code on another board.

Your tests inspired me to try programming the Nucleo32 as a generic G431KB board variant, and it worked like a charm. However, when I tried again as a Nucleo32, it failed.

Therefore, the issue only occurs when the Nucleo32 variant is chosen.

I can live with this workaround, but wanted to let you know.

EDIT: made a few tests with

digitalPinHasSPI(PB3);
digitalPinToPinName(PB3);

when using nucleo variant they return 0 and 268435456 respectively. When using generic g431kb variant they return 1 and 19.

@fpistm
Copy link
Member

fpistm commented Jun 14, 2024

Really strange. Will check that.

fpistm added a commit to fpistm/Arduino_Core_STM32 that referenced this issue Jun 17, 2024
@fpistm
Copy link
Member

fpistm commented Jun 17, 2024

OK. Found the issue, it misses some PinName in the digitalPin array.
See #2043.

@fpistm fpistm added the bug 🐛 Something isn't working label Jun 17, 2024
@fpistm fpistm added this to the 2.8.0 milestone Jun 17, 2024
@acunipisa
Copy link
Author

OK. Found the issue, it misses some PinName in the digitalPin array. See #2043.

Great. Thank you for your work. Bests

@fpistm
Copy link
Member

fpistm commented Jun 17, 2024

If you can test to validate this is the only issue 😉
I'm confident this will fix your issue.

@acunipisa
Copy link
Author

If you can test to validate this is the only issue 😉 I'm confident this will fix your issue.

Tested, It works! Thank you!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Something isn't working
Projects
Development

Successfully merging a pull request may close this issue.

2 participants