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
