Selecting GPIO in shared pins for STM32G030F6

[NGiussani]

In pins that share more than one GPIO, how do you set the GPIO to connect to the physical pin?

For instance, for pins PA12/PA10 and PA11/PA9 one can remap them using SYSCFG_CFGR1 register. But is unclear for the rest of the pins. For example, TSSOP20 case pin #20 shares PB3/PB4/PB5/PB6 and #15 PB0/PB1/PB2/PA8.

I'm not using Cube, but I tried it to see what it is generating. I think it is the Cube itself the one that limits what you can select. In bare metal applications, neither Datasheet nor Reference Manual mention anything about those GPIO.

[waclawek.jan]

They are probably just bonded together in the package, as they are in the SO-8 package too.

This ought to be properly documented. @Imen DAHMEN​ , can you please have a look at this? Thanks.

JW

[Imen.D]

Hi @Community member​ ,

Happy new year :smiling_face_with_smiling_eyes:

PB3/PB4/PB5/PB6 are bonded together on some package, but PA10 can be remapped on PA12 by syscfg setting.

This is two different approaches readable from the datasheet and reference manual specification.

Which type of clarification or information would be required in the documentation ?

Imen

[waclawek.jan]

Hi Imen,

> Which type of clarification or information would be required in the documentation ?

The mere fact that those pads are bonded together.

The footnote under Pin assignment and description table in DS12991 Rev 3 mentions pin 4 for SO-8 package; but all those pins where pads are bonded together ought to be marked clearly in DS, for each package where this occurs.

Also, RM in GPIO chapter should warn against setting such connected GPIOs to mutually conflicting output state (even through AF).

Happy 2021!

Jan

[Imen.D]

It’s obvious from pinout table and diagram, (they have same pin number and are located on same pin)

Comment on pad 4 of SO8 concern particular situation of NRST pin.

Then it’s not a matter of reference manual to warn package dependant bonding. The datasheet is precisely here to present this.

Maybe a note can be added to describe concept of multibonding in DS. So, I raised your request internally and it will be consolidated with the appropriate team.

This approach will most likely be generalized in small pincount devices in future.

Imen

[waclawek.jan]

Hi Imen,

> Then it’s not a matter of reference manual to warn package dependant bonding.

I beg to disagree. True, RM should not discuss the minutiae of different bondings; however, the RM ought to warn that there is a possibility of pads being bonded together, as it is unusual and potentially dangerous ("in smaller packages some pads may be bonded together, don't set them to conflicting outputs or AF turned to output" - btw. did you notice that I am trying to use consistently "pad" in this context, as there is no more 1:1 relationship between pads and pins? It's not an ideal terminology but I believe, in this particular case, something has to be done to distinguish the physical pins from the GPIO terminals).

You are looking at the problem with an apriori knowledge of this possibility. Please try to look at it from the perspective of the user who never thought this may be possible at all (heck, most users are not even aware that the different packages contain the same physical chip - nowhere in the documentation is this said out explicitly!). They may quite well assume that there's enough "magic" built into the chips that they avoid being self-destructible. For example, the designers might've implemented "correct" signal merging in the chip's logic, configured by bond-down or by factory-set option bit. Or, there may be a multiplexer, selecting one of the IO based on some smart priority decoding.

IMO, there can never be too much documentation.

> Maybe a note can be added to describe concept of multibonding in DS. So, I raised your request internally and it will be consolidated with the appropriate team.

Thanks.

> This approach will most likely be generalized in small pincount devices in future.

That would be nice to see, thanks again.

Jan

[Imen.D]

Hi @Community member​ ,

I already passed your message internally and we appreciate your opinion and continued feedback.

I would inform you that our marketing team will contact you for more details and take a decision in consequence.

Regarding naming, we agree that we must be cautious and clear on our terminology. 

Thank you for your kind cooperation.

Imen

[waclawek.jan]

Thanks, Imen.

Jan

[JLehm.2]

Hi Imen,

good that we found this conversation. We also did not understand that some ports are bonded out to the same pin. Also we are wondering that there are no hints that there might be dangerous settings. I guess it would not be a good idea to set all those ports to push pull output and different output level. Is there a kind of build-in self-destruction?

@Community member​ : thanks for pointing this out

[Sreenath]

Hi All,

reviving an old thread. I have some questions regarding the pins on stm32g030f6p6. Pin 1 is both PB7 and PB8. Pin 20 is PB3/PB4/PB5/PB6. The alternate functions associated with each of these physical pins are different and dependent on the base GPIO pin configuration. So if one has to use a specific alternate function, it is first necessary to configure a pin to become one of the possible GPIO pins. 

The datasheet or the reference manual do not mentions how exactly this is to be done.

The datasheet specifically calls the various possibilities (PB3/PB4/.....) as Pin Name function UPON RESET. So there must be some configuration that is required.

I believe I have read the datasheet and ref. manual a few times and have not figured out how to do this.

Any help appreciated.

thanks,

Sreenath