Embedded developer blog on microcontrollers, ARM Cortex-M, FreeRTOS, debugging tools, and DIY electronics projects.
HN commenters link its practical embedded posts, such as avoiding dynamic memory, address sanitizer on microcontrollers, and low-power techniques.
In my sibling comment about the overall systems aspects of the situation, I asserted that there was in fact enormously more information available for how to program in the 32-bit ARM assembly used by the ATSAMD20 than in Z80 assembly. This is an overview of that information, starting, as you did, from the Internet Archive's texts collection.
Searching the Archive instead for [arm thumb programming] I find https://archive.org/details/armassemblylangu0000muha https://archive.org/details/digitaldesigncom0000harr_f4w3 https://archive.org/details/armassemblyforem0000lewi https://archive.org/details/SCE-ARMref-Jul1996 (freely available!) https://archive.org/details/armassemblylangu0000hohl https://archive.org/details/armsystemarchite0000furb https://archive.org/details/learningcomputer0000upto https://archive.org/details/raspberrypiuserg0000upto_i5z7 etc.
But the Archive isn't the best place to look. The most compact guide to ARM assembly language I've found is chapter 2 of "Archimedes Operating System: A Dabhand Guide" https://www.pagetable.com/docs/Archimedes%20Operating%20System.pdf#page=20, which is 13 pages, though it doesn't cover Thumb and more recently introduced instructions. Also worth mentioning is the VLSI Inc. datasheet for the ARM3/VL86C020 https://www.chiark.greenend.org.uk/~theom/riscos/docs/ARM3-datasheet_ARM-Family-Data-Manual-VLSI.pdf sections 1 to 3 (pp. 1-3 (7/56) to 3-67 (45/56)), though it doesn't cover Thumb and also includes some stuff that's not true…
I can add a bit of historical context here. John wrote that during the development of WINAVR, the first GCC compiler for AVR. The discussions can be found in the AVR-GCC mailing list archives.
When the 'Small' optimization is used in AVR GCC it is aggressive and leads often to broken code if 'volatile' is not properly used.
AVR GCC, using Small optimization, would remove any variable that has no side effects from the compiler's view. Setting a value in an interrupt handler would be outside of the view of the compiler's abstract machine, so 'flag' variables were often removed. Changes in hardware registers fall into the same category.
These removals result in broken code.
Volatile is never a replacement for atomics or proper locks/mutexes/semaphores.
If hardware such as an interrupt handler or hardware register is not involved, then using volatile is a creating a race condition, which may or may not ever become apparent.
Erich Styger wrote more recently about volatile here.
https://mcuoneclipse.com/2021/10/12/spilling-the-beans-volatile-qualifier/
John and I both make an appearance in the linked parent particle to that one.
Any earlier one of Erich's:
https://mcuoneclipse.com/2013/08/14/volatile-can-be-harmful/
If changing the optimization level breaks something, it is probably a missing volatile when doing bare hardware.
I found k3s to be VERY noisy in logs - I definitely recommend log2ram if you want your SD card to last very long! (Or use different external storage). I had two Pi nodes with corrupted filesystems until I made the switch.
https://mcuoneclipse.com/2019/04/01/log2ram-extending-sd-card-lifetime-for-raspberry-pi-lorawan-gateway/
Hmm, maybe you could possibly instrument the functions[1] to write the function address to a register, presuming you have enough program space. Presuming you're in C and your compiler supports that.
1: https://mcuoneclipse.com/2015/04/04/poor-mans-trace-free-of-charge-function-entryexit-trace-with-gnu-tools/
Adding to other replies
https://mcuoneclipse.com/2021/05/31/finding-memory-bugs-with-google-address-sanitizer-asan-on-microcontrollers/
https://interrupt.memfault.com/blog/ubsan-trap
I've tested the UBSan, it worked with some limitations but helped me catch some old hidden bugs.
The link leads to some politics article that is not accessible in the EU.
This is probably the correct one: https://mcuoneclipse.com/2024/05/22/low-power-optimization-techniques-for-arm-cortex-m0-microcontrollers/