How to handle entropy and CTR DRBG for TLS on embedded system? I am trying to use mbedTLS on a STM32-Nucleo microcontroller (STM32F746).

The TLS library wants a RNG function (naturaly), the STM32 has a hardware RNG verified according to NIST SP 800-22. 

The hardware RNG only outputs unsigned 32 bit integers each call, but several calls could provide 28, 32 and 255 byte random arrays needed by TLS.

Now, can/should I use this RNG function to generate random numbers directly for TLS or should I use this Hardware-RNG as Entropy for mbedTLS CTR-DRBG function?
Unless you have documentation about the RNG interface that states that it's using a cryptographic PRNG seeded by an entropy source, use it only as a seed to a PRNG. (Seed initially, and re-seed from time to time as directed by the PRNG algorithm and possibly by certification requirements. Since you're using an existing PRNG library, just pass it the seed function and let it manage when it seeds.)

A hardware RNG always has biases. Those biases may be negligible or not depending on conditions, for example it may perform poorly at certain temperatures or if the power supply is not optimal. A cryptographic PRNG removes observable correlations from the RNG. Even if the seed is not perfectly uniform, the PRNG hides the biases: either the attacker manages to guess the whole seed (i.e. the whole HRNG output), in which case all is lost anyway, or the attacker only manages a partial observation (e.g. after a 1 bit, there's a 50.1% chance that the next bit is also 1) and the PRNG makes that observation useless on its own.

An ideal system uses a HRNG that's unconditioned, i.e. that has no mechanism to eliminate biases, and runs some basic tests about its output based on the known failure modes (e.g. a particular sensor might return all-bits-0 if not properly initialized). The output is then used to seed a PRNG. When that process is hidden in a black box labeled “RNG”, it's hard to verify that the entropy source is operating correctly.