The nucelo ones are even weirder. The pins aren't labeled on the board, and they're in a weird layout, with some male and others female.
Nah, you got it all wrong. You need to pull up the devboard's Pinout, User Guide, and Overview documents. Sometimes cross reference those to the devboard's schematic for the trickier pins. Alongside the specific User Guide and Programming manuals for the MCU on the board. Plus the MCU's guides don't typically cover stuff that's common to all MCUs in a particular Cortex family, so you need to pull up the Cortex documentation. And then, finally, the errata documents.
Typically speaking you'll need to cross reference across all of those documents, all at once, and several places _within_ each document ... all at once.
That's assuming you're using one of the more common pins. If you've decided to dabble with any of the more exotic functionalities you'll want to pull up one or several Application documents, as the former pile of documentation is unlikely to accurately describe the necessary "voodoo" to get things working.
(I kinda wish this comment was a joke ... but it's not. The STM line of chips are truly wonderful machines but ... golly are they a pain to develop on. There's a reason most people just use Arduino to plaster over this stuff.)
EDIT: Oh and make sure you don't confuse the labeling of the pins on the board, with the label of the pins on the pinout, with the label of the pins on the schematic, with the label of the pins in the registers, with the label of the pins in the various HAL libraries...
EDIT2: Geez, how could I forgot the most crucial thing: you of course have to modulate all of these by which specific package of the chip you're actually working with. No sense spending half an hour of your life wadding through all of this documentation only to get to the dev board pinout to find that pin is only available on the largest package and the dev board only came with the 2nd to largest package... (and also doesn't include that one peripheral you were planning to use because ... reasons).
For example, the RTC periph is the same on most STM32 devices. Clocks vary significantly between families, as expected, but at their core, are just different combos of multipliers and internal oscillators, which you can break out by comparing clock trees. Things like I2C vary wildly between families, and sometimes within families.
There's actually two major versions of the RTC peripheral. :) The v1 RTC counts in seconds, v2 has explicit date/time fields.
A lot of other STM32 peripherals can be seen as "versioned" in similar ways. There's a lot of different combinations of those peripherals on different parts, but there's usually only two or three major revisions present of each peripheral across the entire product line, and they tend to follow a pretty consistent timeline. (That is, a newer part will usually use the newest version of each peripheral at the time it was designed, rather than using a mixture of old and new peripherals.)
Then there's also device & device family xml files that link to the various peripherals they have [2].
There's probably no guarantees but in my experience if two devices link to the same version xml file their peripheral registers at least will be identical. Quirks and silicon bugs, you are on your own of course... but then the ref manual doesn't help with that either!
[1] https://github.com/esden/stm32cube-database/tree/master/db/m...
[2] https://github.com/esden/stm32cube-database/tree/master/db/m...
Signed,
Someone who needs 200+ pins in a current design and doesn't want to make their own board from scratch.