I've experienced plenty of similar bugs that don't manifest when running under a debugger while working on modern ARM systems (not that any of it is necessarily

I've experienced plenty of similar bugs that don't manifest when running under a debugger while working on modern ARM systems (not that any of it is necessarily specific to ARM, it's just what I work on). Usually it's one of the following causes: The boring one which should show up as a warning in the compiler: use of code with undefined behavior, which could be something as simple as an uninitialized variable or in manually written assembly use of an instruction in a context in which it has undefined behavior. Bugs caused by poor understanding of the memory model: ARM has a weakly ordered memory model, which allows for various hardware optimisations, but the (systems) programmer has to understand it. The basic idea is that memory accesses could be observed in different order in different coherent cores, so synchronisation points require carefully placed barriers. Bugs caused by not accounting for the modified Harvard architecture: the data and instruction caches aren't coherent. If you do JIT you'll notice odd behavior soon enough when some executable code is overwritten, but if it's just one time dynamic code generation, there's a fair chance most of the time there won't be any stale data in the instruction cache. Until there is, you get odd erros and if you inspect the code in the debugger it will look just fine, since it's fetched through the data cache. DMA bugs: if the DMA peripheral isn't connected through a cache coherent bus, it can be quite tricky to ensure you won't accidentally transfer stale data. Finally, something that's not so much influenced by using a debugger, it's just that the debugger is completely useless: silicon bugs. Just a few weeks ago, I found a bug in a MCU which causes it to send multiple copies of an SPI transfer for certain ratios between the peripheral's clock and the core's clock. It was relatively easy to find since SPI is an external bus which I could probe with a scope, but if a similar issuue would happen on chip, it would be a lot more tricky.