Ideally the program design should be tied up with your requirement specification, so that for each requirement there is a code module, and for that code module there is a test demonstrating how it lives up the requirement. It's kind of an utopia that one rarely manages to uphold in practice, but this kind of design is a good ambition anyway.

Then generally, it is not as important how you document the program design, as long as the overall design gets at all documented - this is surprisingly rare even in professional settings. But all the pedantic details of UML are really optional, use them where you find a case for them, don't use them just for the sake of it. I frequently use UML class diagrams to document code dependencies, as well as state charts which are useful for documenting application behavior. And so on - keep it broad without implementation-details.

The C equivalent of a class is typically a .h/.c pair with the same name, together forming a "module" or "ADT" or whatever you wish to call it.

You need to document all class A uses class B dependencies, as well as all class B is a class A dependencies (inheritance). Inheritance isn't very common in embedded systems, but implementing a HAL is a typical example where it is used. You have an abstract API on top of hardware-specific drivers.

Obviously you need to decide early on if such abstractions are justified - will the program eventually get ported to another MCU or do you count on the silicon vendor's "longlivety" assurance that the MCU will not go End of Life within the expected product life time? Looking at the completely broken silicon market as of today, I would assume that any microcontroller project needs to get ported plenty of times during its life time.

To model an overview of the static structure of a large application written in C, I would recommend a package diagram. The packages in the diagram would represent the subsystems, most likely corresponding to the high-level directory structure of the application. Dependency arrows between these packages would indicate which subsystem makes use of which other subsystem(s).

For each top-level package, you could create a separate package diagram, showing the subsystems/subdirectories and their dependencies.