Some ''additional functions'' of pins not indicated in CubeMX (eg: BOOT1)

[Kamil Kisiel]

Posted on January 03, 2018 at 19:25

I recently had a problem in one of our designs that was caused by assigning a GPIO with an external pull-up to PB2 on an STM32F413. It turns out that this pin has the additional function of being BOOT1, so the pullup caused the MCU to be unable to enter the system bootloader mode. I use CubeMX to plan my pin assignments, and this additional function isn't indicated anywhere in the user interface. Yes, I probably should have caught this by cross-referencing the report with the datasheet, but this is definitely an area where CubeMX should be able to help me out.

st.mcu

‌ can you please pass this feedback on to the CubeMX team?

[Jeanne Joly]

Posted on March 08, 2018 at 09:05

Hello

Kisiel.Kamil

,

Taking the example of the STM32F469IEHx where PB2 is indicated as BOOT1, you don't have the signal BOOT1 on PB2 as once BOOT1 has been sampled, the corresponding GPIO pin can be freed and used for other purposes :

In the <LINK NO LONGER ACTIVE>

, the boot configuration is well described.

BR. Jeanne

[Kamil Kisiel]

Posted on March 08, 2018 at 15:14

Ok, so it looks like for the F469IEHx CubeMX correctly indicates that PB2 is also BOOT1. How come that doesn't happen on the F413CHUx in my example?

[Jeanne Joly]

Posted on March 08, 2018 at 17:13

it comes from the datasheet....

[Jeanne Joly]

Posted on March 08, 2018 at 18:29

Hello all, 

A further study on the pin names that are not dedicated to the BOOT will be started thanks to your posts (this concerns different MCUs).

And we will add the pins PC13, 14 and 15 as well in that study (vs pin name).

BR. Jeanne

[Tesla DeLorean]

Posted on March 08, 2018 at 17:34

>>Taking the example of the STM32F469IEHx where PB2 is indicated as BOOT1, you don't have the signal BOOT1 on PB2 as once BOOT1 has been sampled, the corresponding GPIO pin can be freed and used for other purposes

Ok, but what part of the original complaint don't you understand?

a) The automated tools DON'T flag the special use case of the pin.

b) If the design has an external pull-up/down it will interfere with the reset case, regardless of the ultimate pin utilization later.

What is being requested is a more explicit DESIGN RULE CHECK flagging if the pin is being used in a user design as say an INPUT. I would tend toward an alert that needs to be cancelled, and comments in the generate code and reports so that the software and hardware guys have a clear heads-up as to where potential pit-falls are.

Perhaps a different colour or shade of pin to indicate it is of SPECIAL IMPORTANCE, and a mouse-over that lists the possible pin functionality properly.

Arguing about what the Data Sheet and Design Guide might contain avoids the point that an AUTOMATIC TOOL really should FLAG this stuff as a HAZARD

Similarly for pins PC13,PC14,PC15 being in a Low Power Domain, being used as outputs, etc.

[Kamil Kisiel]

Posted on March 08, 2018 at 17:50

Thank you, that sums it up better than I could have. I don't understand why there's any argument or pushback here. CubeMX is supposed to be a design tool, and we've identified a deficiency, complete with a specific real world use case where it led to a defect in a design. If ST has any interest in assisting customers this needs to be addressed. It's not something that should be difficult to add to the tool!

The PC13, PC14, PC15 thing has also tripped me up in the past, so that's another point where there should be some kind of warning.

[Tesla DeLorean]

Posted on March 08, 2018 at 18:44

PI8 is on the lower power domain in some parts. And PH0,PH1 frequently have some odd and pairing functionality. I had some headaches with someone else's L0 design in HSE BYPASS mode.

The Murata LoRa module to be specific, HSE BYPASS doesn't work properly with 32MHz TCXO clock input, preventing the use of PH1 as a GPIO, and never got a satisfactory answer about why.