Skip to main content
TDK
October 25, 2017
Question

Any way to determine programmatically what physical pins are on a device?

  • October 25, 2017
  • 6 replies
  • 1939 views
Posted on October 25, 2017 at 17:45

Is there any way to determine programmatically what physical pins exist on a device?  Or, somewhere within the HAL libraries where its defined?

For example, the STM32F411 chip in the UFQFPN48 package only has the PC13, PC14, and PC15 pins on the C port.  Is there a clever way to determine this?  I have determined that if I try to set the PC0 pin as output high, and it doesn't exist, it still reads as low when I probe its value.  However, this behavior is the same if the pin was physically connected to ground on the board.  So I have no way of differentiating a pin that doesn't exist from a pin physically grounded on the board.

The HAL libraries are nice enough to not define ports if they don't exist.  For example, GPIOF is not #defined on the STM32F411xE, but it is defined for chips that have those pins.  So that's somewhat helpful, but doesn't get me all the way there.

The DEV_ID field gives some information on the chip family, but not package size.  I don't see any other useful identifiers apart from that.  The size of the flash is there, but unhelpful.

Any other clever ideas I'm missing?

    This topic has been closed for replies.

    6 replies

    Tesla DeLorean
    Guru
    October 25, 2017
    Posted on October 25, 2017 at 17:51

    A lot of packages share a common die, so they'll all look the same, and frequently have GPIO banks that don't escape to pins.

    Doesn't the UNIQUE ID infer some package size, along with die lot, and X/Y location. Should chat with FAE supporting your project.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    TDK
    TDKAuthor
    October 26, 2017
    Posted on October 26, 2017 at 05:10

    Thanks for the response!

    The UID definitely has X/Y locations and likely lot numbers.  There's a little bit of information floating around, but nothing conclusive from ST that I can see.  I suppose it's possible the package is encoded in there as well.  I probably have enough chips to guess if/where that is.

    If anyone else finds this, here are some useful links I found:

    http://false.ekta.is/2012/06/stm32-device-electronic-signature-unique-device-id-register/

     

    Edit: The forum software deleted half of my original post.  I had more links and info listed.  Nice...

    "If you feel a post has answered your question, please click ""Accept as Solution""."
    waclawek.jan
    Super User
    October 25, 2017
    Posted on October 25, 2017 at 17:54

    Why would this be useful at all?

    JW

    Tesla DeLorean
    Guru
    October 25, 2017
    Posted on October 25, 2017 at 18:38

    One software to rule them all?

    I have dynamic clocking that maps the PLL and AHB/APB to optimal setting by determining which F2/F4 part I'm running on, means I only have to maintain one system_stm32f4xx.c file, and one of my apps will run on whatever STM32F4xx-DISCO I stuff it on.

    For this case I'd either strap the board, or blow some settings into OTP at the test station.

    Tips, Buy me a coffee, or three.. PayPal Venmo (See Profile) Up vote any posts that you find helpful, it shows what's working..
    waclawek.jan
    Super User
    October 25, 2017
    Posted on October 25, 2017 at 19:29

    For this case I'd either strap the board, or blow some settings into OTP at the test station.

    https://community.st.com/0D50X00009XkaBBSAZ

    And it's a specific enough situation to not waste time/onchip-resources for a generic solution.

    YMMV.

    JW