Nucleo 32 G431KB: SPI not working as expected

[acunipisa]

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]

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

Arduino_Core_STM32/variants/STM32G4xx/G431K(6-8-B)(T-U)_G441KB(T-U)/variant_NUCLEO_G431KB.h

Line 106 in 7efecbf

#define PIN_SPI_SCK PA5

See the wiki to know how do this.

[acunipisa]

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..

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

[fpistm]

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

[acunipisa]

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]

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

[acunipisa]

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]

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]

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

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

[acunipisa]

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]

Really strange. Will check that.

[fpistm]

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