NUCLEO-F429ZI SPI pin definitons wrong

[philbowles]

I'm interfacing an SPI SD reader, since the SDIO examples won't compile. The good news is that I have TWO connected successfully on SPI1 and SPI3. The bad news is that I was only able to do that after I realised that the SPI pin defnitions in ...Arduino15\packages\STM32\hardware\stm32\1.9.0\variants\NUCLEO_F429ZI\PeripheralPins.c
bear no resemblance whatsoever to the pin defintions given in the datasheet.

I provided my own replacements in the sketch, copying the values from the datasheet and everything works perfectly. Without them nothing works at all. Are they a "cut and paste" error from a different MCU ? How anyone has ever used hardware SPI on this board is beyond me.

// If you omit these the results are total garbage
const PinMap PinMap_SPI_MOSI[] = {
  {PA_7,  SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)},
  {PB_5,  SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
  {NC,    NP,    0}
};

const PinMap PinMap_SPI_MISO[] = {
  {PA_6,  SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)}, // - D12
  {PB_4, SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
  {NC,    NP,    0}
};

const PinMap PinMap_SPI_SCLK[] = {
  {PA_5,  SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)}, // - D13
  {PB_3,  SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
  {NC,    NP,    0}
};

const PinMap PinMap_SPI_SSEL[] = {
  {PD_14, SPI1, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF5_SPI1)},
  {PA_4,  SPI3, STM_PIN_DATA(STM_MODE_AF_PP, GPIO_PULLUP, GPIO_AF6_SPI3)},
  {NC,    NP,    0}
};

void showSPIpins(void* peripheral){
    PinName x;
    x=pinmap_pin(peripheral,PinMap_SPI_MOSI);
    Serial.printf("MOSI=%d or D%d\n",x,pinNametoDigitalPin(x));
    x=pinmap_pin(peripheral,PinMap_SPI_MISO);
    Serial.printf("MISO=%d or D%d\n",x,pinNametoDigitalPin(x));
    x=pinmap_pin(peripheral,PinMap_SPI_SCLK);
    Serial.printf("SCLK=%d or D%d\n",x,pinNametoDigitalPin(x));
    x= pinmap_pin(peripheral,PinMap_SPI_SSEL);
    Serial.printf("SSEL=%d or D%d\n",x,pinNametoDigitalPin(x));
}

void setup() {
  // Open serial communications and wait for port to open:
  Serial.begin(115200);
  while (!Serial) {
    ; // wait for serial port to connect. Needed for native USB port only
  }

  Serial.printf("\nPIN assignments for SPI1\n");
  showSPIpins(SPI1);
  Serial.printf("\nPIN assignments for SPI3\n");
  showSPIpins(SPI3);
}

void loop(void) {}

With my defintions, the output is as follows:

PIN assignments for SPI1
MOSI=7 or D11
MISO=6 or D12
SCLK=5 or D13
SSEL=62 or D10

PIN assignments for SPI3
MOSI=21 or D22
MISO=20 or D25
SCLK=19 or D23
SSEL=4 or D24

and using those pins allows both SD cards to work on SPI1 and SPI3

Without my defintions i.e. using the wrong defaults from Peripherals.c, the output is:
PIN assignments for SPI1

MOSI=7 or D11
MISO=6 or D12
SCLK=5 or D13
SSEL=4 or D24

PIN assignments for SPI3
MOSI=21 or D22
MISO=43 or D46
SCLK=19 or D23
SSEL=15 or D20

Which are clearly wrong and result in neither SPI port functioning.

[FRASTM]

PA4 is either SPI1 NSS for alternate AF5 or SPI3 NSS for alternate AF6
PA15 is also either SPI1 NSS for alternate AF5 or SPI3 NSS for alternate AF6

However PD14 is not for SPIx

(Table 12. STM32F427xx and STM32F429xx alternate function mapping of STM32F427xx STM32F429xx datasheet DocID024030 Rev 10)

[fpistm]

Thanks @FRASTM
I've also check on my side and there is no issue with the default definition.

MOSI=7 or D11 --> pinName PA_7 is equal to 0x07 where GPIO port A (0x0) and GPIO pin 7 (0x7) --> pinNumber PA7 = 11
MISO=6 or D12 --> PinName PA_6 is equal to 0x06 where GPIO port A (0x0) and GPIO pin 6 (0x6) --> pinNumber PA6 = 12
SCLK=5 or D13 --> PinName PA_5 is equal to 0x05 where GPIO port A (0x0) and GPIO pin 5 (0x5) --> pinNumber PA5 = 13
SSEL=4 or D24 --> PinName PA_4 is equal to 0x04 where GPIO port A (0x0) and GPIO pin 4 (0x4) --> pinNumber PA4 = 24

PIN assignments for SPI3
MOSI=21 or D22 --> pinName PC_12 is equal to 0x22 where GPIO port C (0x2) and GPIO pin (0x2) --> pinNumber PC12 = 21
MISO=43 or D46 --> pinName PC_11 is equal to 0x21 where GPIO port C (0x2) and GPIO pin (0x1) --> pinNumber PC11 = 46
SCLK=19 or D23 --> pinName PB_3 is equal to 0x13 where GPIO port B (0x1) and GPIO pin (0x3) --> pinNumber PB3 = 23
SSEL=15 or D20 --> pinName PA_15 is equal to 0x05 where GPIO port A (0x0) and GPIO pin (0x5) --> pinNumber PA15 = 20

the pinmap_pin() extracts the first one found. It seems strange you are able to get MOSI=21 or D22: where 21 would be PC1 and D22 is PB5 morover PB_5 is commented in the original file...

SPI has been tested since a while and as mentioned by @FRASTM PD14 has no SPI capabilities. I guess to read the wrong datasheet.
If you met an issue with SPI, I guess it could comes from the fact the PA7 is shared with Ethernet RMII so if you use Ethernet and SPI at the same time this would failed.

[LMESTM]

For information, there is a dedicated wiki page about this specific case on mbed-os.
https://os.mbed.com/teams/ST/wiki/Nucleo-144pins-ethernet-spi-conflict
Key point also applicable to stm32duino is: If you use SPI and not Ethernet, you should remove JP6 jumper on the front side of the board.

Hope this helps.

[philbowles]

"I guess to read the wrong datasheet" - I gave you the link to the datasheet I used. My reference to it which clearly shows your answer to be incorrect seems to have been removed - is there any reason for that? Anyway, here it is again, direct from the ST website:

https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-stmicroelectronics.pdf

And here is a screenshot (again) that proves your answer wrong "SPI has been tested since a while and as mentioned by @FRASTM PD14 has no SPI capabilities"

How do you explain the above? Also how do you explain that when I use the values that you claim are correct, that neither SPI1 nor SPI3 work, but when I put in the correct figures from ST's own datasheet it works perfectly?

So, yes - "I guess to read the wrong datasheet" - but it is you that is reading the wrong datasheet, not me!

[fpistm]

I gave you the link to the datasheet I used. My reference to it which clearly shows your answer to be incorrect seems to have been removed - is there any reason for that?

Nothing has been removed from your post... You can check by yourself:

About the Nucleo datasheet, you are right, this is mentioned anyway looking to the MCU datasheet, there is no SPI CS:
https://www.st.com/resource/en/datasheet/stm32f429zi.pdf

I will raise an issue internally to fix the Nucleo datasheet.

The fact it works with PD14 doesn't means this is an HW CS just it is used as an SW CS.

Please, note that the PeripheralPins.c is generated automatically thanks the MCU XML description file from STM32CubeMX, as you can see below there is no CS capabilities.

Anyway those XML files can have an issue but is rare, in our case the Nucleo datasheet is not correct.

And here is a screenshot (again) that proves your answer wrong "SPI has been tested since a while and as mentioned by @FRASTM PD14 has no SPI capabilities"

Our answers were correct and when I said it has been tested since a while this is correct. I never told a regression can occur anyway this is not the case.

So, yes - "I guess to read the wrong datasheet" - but it is you that is reading the wrong datasheet, not me!

Please keep calm 😉

I remember your comment on an issue when you told:

There is a serious problem in 1.8.0

#841 (comment)

Honestly, I really don't know why this not work on your side...

[philbowles]

I don't see how quoting other datasheets that DON'T show something is justification for STILL arguing about the datasheet that DOES show the correct and working pinout. The datasheet that shows that PD14 is used for SPI CS not only contradicts what you are saying - twice - but also does not match the definitions in the stm32 peripherals.c file - they cannot both be correct! Why can you not understand or accept this?

No-one has yet explained to me why when I use the CORRECT and EXACT values from the data sheet ...everything works perfectly but if I use the garbage in peripherals.c ... NOTHING WORKS? your own documentation proves you wrong.

I am not using stm32cube - it has NOTHING to do with this issue. Read this for the third time and tell me again PD14 is not used by SPI:

How many more times are you going to tell me that PD14 is not the SPI CS pin when a) IT WORKS and b) NOTHING else you have said so far works c) your own documentation states in black and white above that it is? How can I trust anything you are telling me when it appears you cannot even read your own datasheet when it has been pointed out to you three times already?

"Honestly, I really don't know why this not work on your side..." given the amount of incorrect information you have provided so far, I'm not surprised. Yet again you have completely missed the point or ignored what I am saying: IT DOES WORK ON MY SIDE but only when I use the correct pins from the datasheet and NEVER when I use any of the incorrect information you keep giving me, after I have sifted it from all the irrelevant information you keep giving me.

I am not asking a question, I do not need or care about any of the irrleveant information you keep replying to me - I am telling you that the pin definitions in peripherals.c DO NOT MATCH THE DATASHEET. I am telling you that the pins in the datasheet work and the pins in peripherals .c don't work. There is nothing that needs to be answered, nothing I want to hear from you except "thanks, we fixed it". Please tell me what it is that you do not understand about that?

[fpistm]

Well' fine. As the PeripheralsPins.c has been made to allow the user to customize it for their needs and that it works for you. There is no issue. It seems we cannot discuss and find what exactly is the issue. It works for you and me so no one is blocked.

[LMESTM]

@philbowles I'll just share my 2 cents.

First I think there is no need to get upset, I don't think that Frederic has provided any wrong information. There is a difference between SSEL and CS and it seems to me that this is the origin of the misunderstanding so far.

The NUCLEO 144 board datasheet refers to SPI1_CS which is the Chip Select signal from board point of view. This CS can be implemented

• either by SW using a GPIO (any GPIO which makes it very flexible, you can use ANY pin for CS). In this case, it is up to the application or driver (like SDcard driver) to position the CS pin when needed.
• or by connecting the CS pin to the internal SSEL of SPI Peripheral thanks to the Alternate Function function. In this case, the HW will position CS pin through SSEL any time there is a transaction.

The fact that PD14 is mapped to SPI1_CS does not tell us which of the above method is being used.
If we want to investigate further, we need to know how the driver or application is using CS (GPIO or SSEL), so we would need to know which SD card reader code you are using. Could you point to it ?

To explain a bit further: the PeripheralPins.c contains the list of possible Alternate Function including the ones for SSEL (i.e. to be used when the Chip Select functionality is fully handled by the HW SPI peripheral including the SPI peripheral SSEL pin). This SSEL HW peripheral signal is not often used, most SPI applications use a GPIO for CS control. This list of available Alternate Functions are listed in the MCU datasheet, not the board datasheet. So the table canot be updated accoring to Board datasheet, it needs to reflect MCU datasheet.

With that understanding in mind, as far as I see now:

• the changes you've done for enablign SPI3 with PB3/PB4/PB5 pins are a valid alternative to the default choice so the tables PinMap_SPI_MOSI/MISO/SCLK can be used as such in your application. we should study if those are a better alternative than the default ones proposed today in stm32duino. It also explains why you made it work with SPI3.
• Concerning PinMap_SPI_SSEL I don't think the proposed change can be accepted as such even though it seems to work in your application. We would need the application code to understand further. My guess (only a guess for sure) is that this setting is causing a specific state on the CS pin where SPI slave is always kept active. You may check this by putting a scope on the CS pin.

Again we need the APP context to verify this.

[AnHardt]

The difference between GPIO and Alternate Function becomes really important when they are inputs - in SPI slave mode.

[fpistm]

Official answer:

PD14 is a simple GPIO where the function is to propose to users the way to have a SPI chip select... This is completely independent from the SPI peripheral but provided to match Arduino connector standard pinout. In that case, there is no error in the description done in UM since the pin does not use the name of the SPI peripheral pins.
😉