Struggling finding electrical peripherals interconnection information for STM32F469...

[MKat.1]

Hello, I am struggling finding electrical peripherals interconnection information for STM32F469. Peripherals are not covered in the datasheet, and I have looked thru Application Notes to best of my ability. Is there a document I missed that goes over each peripheral in great detail? Some interfaces, like MUXed and baned ADCs, also need to show a crude representation of circuitry/operation internal to the MCU, for me to understand how to connect pins properly in my PCB. The "AN4488 Getting started with STM32F4xxxx MCU hardware development" is a good starting point, but it stops short of discussing any peripherals other than basic power and setup interconnections. Where do I go to figure out how to interconnect every other peripheral and interface supported by this MCU?

[waclawek.jan]

The Reference Manual, at the beginning of individual peripherals chapters, usually have a block diagram for given peripheral, with input/output signals marked at the edges of the block. Sometimes they are given as a table, e.g. for FMC.

In Datasheet, the alternative functions table then indicates assignment of the signals to individual pins (and the respective GPIOR_AFR setting).

JW

[MKat.1]

Hello,

I have looked thru datasheet, Application Notes listed under this processor, its Reference Manual, etc. I have already seen this info. This is software-level info. I am drawing up the schematic, and I am missing a whole bunch of information related to every single peripheral, at an ELECTRICAL level. The AN4488 is a good example of electrical-level detail and discussion for pins... To give two easy examples:

Obviously, I2C requires external pullups or activation of internal pullups.

CAN usually requires termination resistors and a common-mode choke.

USB is sort of covered in some other Application Notes.

For internal circuitry, I can guess with some difficulty inter-connections of internal ADCs, MUXes, and "common" signals, but the "common" ADC inputs in particular worry me. I would like to see at least a simplified schematic of internal connections to ADCs.

For interface to memories, a few examples in such an Application Note would be a good idea.

I also have the Evaluation Board design information, but only a few interfaces are used to the Eval Board, so I can't use that to answer all of my questions...

[Tesla DeLorean]

I don't think ST's in the business of tutorializing the jobs of SW, HW and PCB/CAD staff, there's the assumption people in the design team will come trained and work collectively to pick pins and combinations of peripherals, how they escape and the voltage level other down stream circuits and components expect. An Army-of-One is going have to do a lot more work, be more resourceful and connect a lot more dots.

How CAN transceivers work, and how I2C buses are constructed is a bit beyond the scope of the Reference Manual and Data Sheets.

The IO cell is documented, the drive strength/slew rate stuff is also in there. Individual currents, total collective currents across all pins/banks.

The pin connectivity matrix/mux is in the Data Sheet, its going to be limited by the pins and package selected, whereas the common die covers a broad array of packages.

There should be schematics for the EVAL, DISCO and NUCLEO boards both for your F4 part, and an array of other STM32 family of parts which share a common heritage, and beyond that a broader array of what people have done with 3.3V MCU for decades.

[MKat.1]

Hello,

I don't necessarily disagree.

I am already quite pleased that full design info is available for supplied evaluation boards. Still, as I said, evaluation boards cover only a short portion of all available I/O options (and precisely the I/O that I am not interested in).

I am trying to make my own eval board for the public which breaks out, individually, all the separate I/Os, with their own appropriate drivers/filters/circuitry, all ready to be connected via headers. I don't want to route a trace from a BGA ball to an external header and say my job is done for my customer to then figure out what the heck to do with the connection. If it is a CAN interface, it should be ready to go, terminated and filtered. I2C will have an active-pullup / accelerator IC on board instead of passive pull ups, and so on. OK, I could try my best to guess at proper connections, but screw up on my first design iteration... I am going to spend a year of my life on this design, why do it wrong from the start??? I am asking people who already read all the standards to come up with internal wiring to share their info and wisdom.

I see this as benefiting the customer, as releasing such an Application Note will create more business to ST. Let's hint that there are competitors, some have better or worse documentation, so winning customers to your own brand with good documentation is the goal, is it not???

[MKat.1]

I have just wasted a week extracting the pinout from the PDF into a super-fancy spreadsheet with more and more details added from the datasheet for each pin and function. Easiest example of making your customer's job easier: why did someone convert a spreadsheet into PDF format, only for me to spend days and days on the semi-manual process of converting the crappy PDF format back to a proper spreadsheet file? Why not post a pinout file like most people do?

So now I have a n-th dimension task of splitting a limited number of I/O, with a whole bunch of alternate functions, into a maximum number of independently usable I/O types...

[MKat.1]

Thanks for the tip though to look at other eval boards... "For my part" only exists a 32F469IDISCOVERY board, and I have an M7 Nucleo that I purchased as well, so I will check out schematics for *-EVAL et al for other part numbers close enough to the M4F STM32F469. Stil, I see some RS232 that is added on the -EVAL, I doubt every interface like CAN will be covered even across these three boards...

[Piranha]

Exploring and combining pin configurations is actually one of the few tasks for which STM32CubeMX is actually useful.

[MKat.1]

Thanks! I actually already saw a screenshot reference to this in the datasheet, but have not had time to explore this...

[waclawek.jan]

> Exploring and combining pin configurations is actually one of the few tasks for which STM32CubeMX is actually useful.

If you are not into clicking, CubeMX has an "mcu" directory which contains individual chips' description in xml format (they lack a bunch of vital information, but at least the basic pinout/AF is there). On my website there's a simplistic "mcu2csv" command-line utility which converts individual xml files from there into csv which can be then imported into a spreadsheet program.

While I understand your sentiment and ST might do more to educate in this direction (I believe there may be dozens of appnotes per peripheral), truth is that there isn't a single "best practice" for almost no peripheral.

Take for example I2C, the basics are described in the I2C standard in surprisingly great detail, nonetheless there's still the SMBUS variety which has its own set of tips and tricks.

Or take the venerable UART, I've seen at least a dozen of hardware implementations, ranging from standard RS232 (which in itself has quite a couple of quirks) through unbalanced push-pull, open collector with various pullup schemes, galvanically decoupled - straight or modulated, down to the IrDA and smartcard flavours...

JW