2026-04-29 11:41 AM
I am using STM32CubeIDE for a project using custom hardware with a STM32G0B1CBT6.
I recently hit a bug where my code was doing a 32-bit write to an address that wasn't on a 32-bit boundary (off by 2 bytes) and a Hard Fault was generated.
I've corrected the code to avoid this, but this same code worked OK on an earlier project - which used Keil uVision and a STM32F103C8T6.
I've seen references to compiler options to control this behavior, but I've not found them in CubeIDE or Keil. Am I wrong here? Or can someone point me to where those options might be? Or is this some kind of difference between these two chips?
Also: I'm on the fence about whether this is a good feature or not. On the one hand, avoiding unaligned memory seems fairly easy. On the other hand, Hard Faults really cause havoc in my world.
Solved! Go to Solution.
2026-04-29 5:48 PM - edited 2026-04-29 5:55 PM
One possible short answer is that STM32G0 is a Cortex-M0+ and STM32F1 is Cortex-M3. These ARM cores differ in handling unaligned memory accesses.
About different compilers and options: this is complicated. TL;DR: All decent compilers that support attribute(packed) or __packed on structures, also support seamless access to unaligned fields in these structs.
But access to unaligned fields in packed struct thru a random pointer isn't warranted to work on CM0+ with any compiler or without special options. It will likely work on CM3, because of the hardware ability.
Keil and IAR have better support for unaligned operations, this is one of reasons why they cost more.
For more information and practical advice you can ask your favorite AI. These things are very fond of C and ARM programming and enjoy explaining in great details.
(*) Googling yields that Cortex-M0+ may have unaligned accesses, almost like in M4, but ST does not seem to enable this in their M0+.
2026-04-29 5:48 PM - edited 2026-04-29 5:55 PM
One possible short answer is that STM32G0 is a Cortex-M0+ and STM32F1 is Cortex-M3. These ARM cores differ in handling unaligned memory accesses.
About different compilers and options: this is complicated. TL;DR: All decent compilers that support attribute(packed) or __packed on structures, also support seamless access to unaligned fields in these structs.
But access to unaligned fields in packed struct thru a random pointer isn't warranted to work on CM0+ with any compiler or without special options. It will likely work on CM3, because of the hardware ability.
Keil and IAR have better support for unaligned operations, this is one of reasons why they cost more.
For more information and practical advice you can ask your favorite AI. These things are very fond of C and ARM programming and enjoy explaining in great details.
(*) Googling yields that Cortex-M0+ may have unaligned accesses, almost like in M4, but ST does not seem to enable this in their M0+.