STM32 unaligned access

Question

Periodically, the program enters the HardFault_Handler. In the register HFSR set bit FORCED and in UFSR register set UNALIGNED . The project uses STM32F417, FreeRtos, LWIP. In most cases, the error in the stack are LWIP function. The error occurs rarely once a few days. The program is compiled with the flag --no_unaligned_access . It is unclear why there is such an error - while --no_unaligned_access flag is enabled and even every few days, and second whether it is possible to process or ignore this error and continue the program?

Answer 1

(I know this is years after the OQ. Posting in case it's still helpful.)

I'm working on a project that is using LWIP 1.4.1 that does have at least one unaligned access fault; I've just now fixed it. (I'm here researching if this is a known issue.)

In src/netif/etharp.c: etharp_request()

  return etharp_raw(netif, (struct eth_addr *)netif->hwaddr, &ethbroadcast,
                (struct eth_addr *)netif->hwaddr, &netif->ip_addr, &ethzero,
                ipaddr, ARP_REQUEST);

The cast (struct eth_addr *)netif->hwaddr is causing the non-alignment of netif->hwaddr to be discarded. A subsquent memcpy() inside etharp_raw() then faults.

The solution I've shoe-horned in is to allocate temporary storage that is aligned and pass that instead:

  struct eth_addr hwaddr;
  memcpy(hwaddr.addr, netif->hwaddr, ETHARP_HWADDR_LEN);

  return etharp_raw(netif, &hwaddr, &ethbroadcast,
                &hwaddr, &netif->ip_addr, &ethzero,
                ipaddr, ARP_REQUEST);

A quick check through the rest of etharp.c reveals quite a number of such casts, some of which are harmless but at least one or two others are also likely to fault.

Answer 2

lwIP 2.x has been released since mid-last year (2018). My experience is that changing over from 1.4x to 2.x did not cause any/much issues, so it's best to switch over. That sort of problems (if they are actual problems) might have been fixed.

Also, the F4x series is Cortex-M4, so they can do unaligned access. It would only cause problems if you are using F0xx or L0xx series that uses the Cortex-M0+ core.

Answer 3

I don't know if this is already resolved. But I ran into same problem with (STM32F746) during one of the project. Here is one application note from IAR:

STM32 unaligned access

Solution: Just add

SCB->CCR = SCB->CCR & ~(1<<3);//Resetting the 3rd bit (meant for enabling hardfault for unaligned access)

Check if it is still relevant for you.

In my case I was using packed structures which was causing this problem. After above mentioned fix with option 1, it got away for me.