cancel
Showing results for 
Search instead for 
Did you mean: 

Questions about Unaligned memory accesses and Hard Faults

Jim Seymour
Senior

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.

 

1 ACCEPTED SOLUTION

Accepted Solutions
Pavel A.
Super User

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.

  • CM0 and CM0+ do not allow unaligned accesses at all, and usually throw HardFault (*) 
  • CM3 and newer allow unaligned 16-bit and 32-bit loads and stores in "normal" memory, and they have additional UsageFault exception for unaligned access errors, when they still occur. BusFault exception covers more cases (including unaligned access to something that isn't "normal memory"). By default, all these new exceptions are promoted to HardFault so you can catch only the latter (but still can find out the true reason of exception, if you like to).
  • The ability of CM3+ to do unaligned accesses can be turned off, if you want the old behavior of CM0.

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+.

 

View solution in original post

1 REPLY 1
Pavel A.
Super User

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.

  • CM0 and CM0+ do not allow unaligned accesses at all, and usually throw HardFault (*) 
  • CM3 and newer allow unaligned 16-bit and 32-bit loads and stores in "normal" memory, and they have additional UsageFault exception for unaligned access errors, when they still occur. BusFault exception covers more cases (including unaligned access to something that isn't "normal memory"). By default, all these new exceptions are promoted to HardFault so you can catch only the latter (but still can find out the true reason of exception, if you like to).
  • The ability of CM3+ to do unaligned accesses can be turned off, if you want the old behavior of CM0.

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+.