You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
On MCUs with continuous memory addresses that span multiple memory regions, it's possible to allocate the mempool region across memory regions. While this is typically not a problem, it could become a very subtle bug.
If the following conditions are met, there will be a hard-fault:
The mempool region is allocated across a two RAM regions
The two RAM regions are on different AMBA busses
Code attempts an unaligned access in the mempool, and it falls across the regions
This could prove very difficult to locate and could be circumvented by explicitly allocating a mempool region in a memory region large enough to contain it.
This is a larger problem with spanning regions, but it's easily solvable in this case.
A toolchain/compiler generating code to target an aarch32 architecture that supports unaligned access is free to exploit that feature. The various multilib'd string and memory functions provided by newlib for aarch32 are generally designed to exploit unaligned access support in the target architecture, hence even if -mno-unaligned-access is passed to gcc when targeting an architecture version that would otherwise support unaligned access, the standard libraries pulled in during the link are free to exploit unaligned access. Therefore the allocation of an object spanning multiple memory regions is a bug.
On MCUs with continuous memory addresses that span multiple memory regions, it's possible to allocate the mempool region across memory regions. While this is typically not a problem, it could become a very subtle bug.
If the following conditions are met, there will be a hard-fault:
This could prove very difficult to locate and could be circumvented by explicitly allocating a mempool region in a memory region large enough to contain it.
This is a larger problem with spanning regions, but it's easily solvable in this case.
cc @sg- @bogdanm
The text was updated successfully, but these errors were encountered: