This only works if you're not doing low level stuff.
I recently ran into an issue where an interaction with the DMA controller and the SDRAM controller in a MCU lead to invalid reads from the SDRAM. I still don't know what is actually going on with the MCU (SAME70, in this case).
Using a HAL lets you debug your application code more easily, but I don't think I've ever had a hard problem in an embedded system where the underlying cause wasn't related to some odd hardware behaviour under a corner case stimulus. There's no way to simulate that without a full model of the entire device (which isn't available).
Yeah, the HAL itself does not help much for hardware issues. But if tooling was built for automated on-device tests (to test your HAL and app logic), then you have a much better chance of having a system which can help you reproduce spurious hardware failures. For instance using generative techniques like fuzzing on the software side, or just a predictable test-patterns which can be observed with scope/logic-analyzer.
On the testbench side use temperature stressing, under/overclocking, under/overvolting, adding capacitance or inductance to signal or power lines, modifying grounding schemes, can be done to try to provoke the situation more reliably and (maybe) get a better understand of the problem.
I recently ran into an issue where an interaction with the DMA controller and the SDRAM controller in a MCU lead to invalid reads from the SDRAM. I still don't know what is actually going on with the MCU (SAME70, in this case).
Using a HAL lets you debug your application code more easily, but I don't think I've ever had a hard problem in an embedded system where the underlying cause wasn't related to some odd hardware behaviour under a corner case stimulus. There's no way to simulate that without a full model of the entire device (which isn't available).