A highly amusing reality with ARM MCUs is that they have different and often incompatible peripherals, mapped to highly different areas in the memory space. Worst of all here are timer peripherals, which come in a variety of complexities, with them in general being able to generate any desired output signal on a GPIO pin, including PWM, as well as work as interrupt-based timers to control the execution of the firmware.
Configuring timer peripherals and similar complex peripherals isn't for the fainthearted. Similarly, using a built-in MAC with an external PHY (Ethernet physical interface) requires a lot of in-depth knowledge to know how to configure them. Reading the datasheets and application notes is essential here.
Relying on autogenerated code by tools such as ST's CubeMX software for their STM32 range of ARM MCUs can lead to you wrestling with non-functional code because you forgot to tick a few boxes in CubeMX editor due to not being aware of what those options were for.
There's nothing wrong with using such auto-generating tools, or high-level libraries provided by the manufacturer, as they can make life significantly easier. It's however crucial to accept the risks that come with this decision, as it requires one to trust that the provided code is correct, or to spend time validating that it is indeed correct.
To make the use of peripherals across different MCUs and SoCs less confusing, one has to add a level of abstraction somewhere to allow for portability of the code. The key is to ensure that this does indeed make life easier and not just add another potential issue that may derail the current project or a future project.
