Microcontroller manufacturers go to great lengths to make their products attractive to users. One way how they do this is, that they prepare environments - libraries, IDEs, point-and-click configuration utilities - which are designed to look programming microcontrollers easy. This then includes also very complex interfaces such as ethernet/TCP/IP and USB.

These are incredibly complex interfaces with multiple layers, and with many interactions with hardware, other pieces of software and the whole slew of various devices they connect to. As a consequence, there are also millions of ways how they can break down. It should be understood, that this is not primarily fault of badly designed configuration utilities or buggy underlying firmware, although that's the prevailing view. But the truth is much simpler: there are just too many potential points of failure, which are outside of scope of those, who wrote those utilities and firmwares.

So, it's no wonder, that users often come to places like the STM32 forums with the question similar to the title of this article. There is no good answer to this question, as there are too many things which could have gone wrong, and only the user can find out, what was the problem.

While the genuine answer is - just don't use the pre-chewed version, go out and write your own, maybe inspired by, or partially adopting, what's available - this indeed takes lots of effort, learning, reading, and lots and lots of time. So, it may be worth try and fix the existing "clicked-out" version.

So here are some simple hints, what to try:

• start with a known-good hardware and software: use a Nucleo/Disco/EVAL board. Use provided software example; if possible, use provided binary, to exclude compilation issues.
• if this does not work, check the board's configuration, is it identical with the factory default, haven't there been jumpers removed/flipped
• if this still does not work, assume outside problems: replace cables; for USB try a different USB hub, port, or even a different PC; for ETH check, what IP configuration does the example expect (e.g. a running DHCP server, or network accepting a particular IP address)
• the TCP/IP examples from ST traditionally require ETH cable to be connected (to a switch) when the software is started (because the software expects PHY reporting the appropriate detected mode/speed immediately after reset)
• at this point, if still no success, start debugging as usually; start with checking presence of clocks - USB usually requires an internal 48MHz clock, usually from a dedicated PLL tap, to be set and running (and HS USB also a dedicated 60MHz clock, associated with the PHY); ETH requires a 25/50MHz clock be present on PHY, and then being fed also to dedicated pins on STM32
• these clocks have to be enabled also in RCC; for ETH, the RMII/MII switch has to be set appropriately. Read out the respective registers and check.
• in both interfaces, there is a basic level of setup which is still manageable without having to dig too deep into the details, and that can be checked. In USB, verify, if register controlling the DP pullup is switched on, if it's not in some low-power mode, if packet memory buffers are set up properly. In ETH, check the MDIO/SMI communication between STM32 and the PHY, looking both at physical signals, and content of registers, as software goes through communication with the PHY.
• the OTG USB module in some variant (usually the High Speed one, even if not used as HS) incorporates DMA, usage of which is optional; it may be worth trying it both with or without DMA
• if the interfaces are basically running, and the problem is in some particular detail not working or not working satisfactorily, it is incredibly helpful to have a way to look at the resulting communication from outside - for USB, this means bus protocol analyzers, which may come in the form of dedicated devices (and there are some not-that-extremely-expensive ones around mainly for Full-Speed) or as protocol analyzers in some oscilloscopes and logic analyzers; for ETH/TCP/IP this is usually accomplished with a PC-based analyzer software (Wireshark is a very popular one), in some cases coupled with managed switch which can mirror communication between given ports.