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

[TDK]

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?

[Tesla DeLorean]

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.

[waclawek.jan]

Posted on October 25, 2017 at 17:54

Why would this be useful at all?

JW

[Tesla DeLorean]

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.

[waclawek.jan]

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

[TDK]

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

[TDK]

Posted on October 26, 2017 at 05:17

In this instance, the desire came about as I was debugging an issue on a board.  As part of the debugging, I was checking if pins were shorted to ground where they shouldn't be, or shorted by an external chip through an open drain output or something.  If I have a way to figure out which pins exist, I can avoid checking for nonexistant pins and printing a message about them.

I also have a routine that prints out the configuration status (pushpull or od, pullup/down state, af mode, speed) of all gpio pins.  It would be nice to avoid printing out info for nonexistant pins there as well.

I'm sure there's other use cases.  I'm sure these use cases also have other solutions as well.  As Clive notes below, it's often useful to have a single piece of code which can work with multiple chips.  Flash size is (for my applications) effectively unlimited so I'm not worried about 1kb of additional code size if it help me debug more efficiently/effectively.