2026-05-26 12:30 AM - last edited on 2026-06-05 3:10 AM by KDJEM.1
Hi, I have a problem configuring SPI3 on a NUCLEO-H7S3L8 board.
I’m writing directly to registers and not using any ready-made functions. I configured SPI3 and everything works correctly as long as I use PB4 as MISO. However, I wanted to use PC11 instead, and then I only read 0xFF.
I’m using exactly the same settings for PC11 as for PB4, and both are configured with AF6.
My question is: does PC11 require any special configuration, or maybe something on the Nucleo board blocks it from being used this way?
Solved! Go to Solution.
2026-05-27 12:38 AM
I found the solution — the problem was the default value after resetting the GPIOB MODER register. By default, pin PB4 was configured in AF mode, and AF6 was selected in the corresponding register. Because of that, no matter what I configured on PC11, SPI3 was still “taking over” PB4. Resetting the MODER register for port B, pin 4 solved the problem. The rest of my configuration was correct.
Thank you for your advice — I checked all the GPIO registers and found it. A silly mistake.
2026-05-26 2:13 AM - edited 2026-05-26 2:22 AM
Hello,
Nothing special from NUCLEO board side. PC11 is exposed to both connectors and nothing already connected to it on the board according to its schematic.
What I suggest is to:
1- Start by toggling PC11 and check if it is toggling as intended.
2- Check if you already enabled RCC clock of PC port.
3- Check if you've selected the correct alienate function for SPI3_MISO on PC11. Did you select AF6? (you said you did it but please check):
2026-05-26 2:17 AM - edited 2026-05-26 2:18 AM
Have you used an oscilloscope and/or logic analyser to see what's actually happening on the wires?
@Dziubasku wrote:I’m writing directly to registers and not using any ready-made functions. ?
So have you tried doing it via CubeMX ?
If the behaviour remains the same, that would rule-out any issues in your code.
2026-05-26 3:14 AM - edited 2026-05-26 3:16 AM
I recommend to always start with reading out and checking the relevant registers, in debugger; here GPIO (and RCC if needed). Note, that leaving two pins at the same AF input function, while one of them is permanently high, may lead to perceived inactivity, as they are ORed internally (probably - ST does not document this).
Well, after verifying hardware, of course - which is what @mƎALLEm did here for you. To check if you've used the correct pin on the header, the simplest way is to set it to GPIO output and toggle and measure - this can be done from debugger alone, with no need to write code. Or, vice versa, leaving it to be set as AF, observe given bit in GPIO_IDR and toggle externally.
JW
2026-05-27 12:38 AM
I found the solution — the problem was the default value after resetting the GPIOB MODER register. By default, pin PB4 was configured in AF mode, and AF6 was selected in the corresponding register. Because of that, no matter what I configured on PC11, SPI3 was still “taking over” PB4. Resetting the MODER register for port B, pin 4 solved the problem. The rest of my configuration was correct.
Thank you for your advice — I checked all the GPIO registers and found it. A silly mistake.
2026-05-27 2:09 AM
@Dziubasku wrote:I found the solution.
Great - so please mark your post (not this one!) as the solution.
We’re moving the ST Community to a new platform to give you a better and more reliable community experience.