Hi JW,
NP - embedded debugging can be tricky especially when doing it remotely. Main thing is to eventually pinpoint the issues while making sure we haven't missed any possible related problem that could resurface at a later point.
Regarding this session, the final oddity was again to find that the LSE_RDY flag could get set after enabling the LSE even if no crystal is present. Just the noise on floating pins is probably enough to make it detect enough toggling. I've seen other MCUs a bit more strict with their oscillator detectors, but that's just a detail.
Regarding ST tools, I have never used any generator. The HAL is bloated but I don't fully blame ST devs, it's meant to be a general-purpose solution to abstract hardware and it almost always ends up like this, because those libraries must cover a lot of various cases.
I use the "cube" distributions (taken from ST's git repo) strictly as a SDK, and mostly use only CMSIS and LL files. I actually find their LL layer reasonable compared to many SDKs of other vendors. I personally don't overly like CMSIS code style and find LL definitions easier to read, but of course YMMV. Another plus is that most functions it exposes are actual inline functions, while CMSIS mostly exposes only macros. inline functions are usually as efficient and at least, type-safe. I've otherwise written my own such lightweight layers for other MCUs, but this can be very time-consuming (but at least you get exactly what you want and need).
In any case, I always recommend separating the low-level parts in any firmware as much as possible to make it easier to maintain and easier to port. After that, your pick of the very low-level header files for CPU and register definitions is often a matter of preferences.
