8-bytes is not enough for v8. I would use at least 16.
For armv8:
https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#6452stack-constraints-at-a-public-interface
6.4.5.2 Stack constraints at a public interface
The stack must also conform to the following constraint at a public
interface:
SP mod 16 = 0. The stack must be quad-word aligned.
For 32 bit ARM (including ARMv5):
https://github.com/ARM-software/abi-aa/blob/main/aapcs32/aapcs32.rst#6212stack-constraints-at-a-public-interface
6.2.1.2 Stack constraints at a public interface
The stack must also conform to the following constraint at a public
interface:
SP mod 8 = 0. The stack must be double-word aligned.
On Sun, 15 Mar 2026 at 16:16, Nathan Hartman <[email protected]>
wrote:
> On Fri, Mar 13, 2026 at 2:03 PM Peter Barada <[email protected]>
> wrote:
>
> > I've run across a crash on a few different STM32 Nucleo boards (h743zi2,
> > f767zi, and f446re) caused by the Idlestack not being8-byte aligned due
> > to syslog messages at startup (with timestamps enabled) that passes a
> > uintmax_t parameter to vsprinf_internal().
> >
> > I originally found this on nucleo-h743zi2:jumbo while trying to fix the
> > "Missing logic" warning in stm32_irq.c:152 I've been able to apply my
> > same changes to nucleo-f446re and nucleo-f767zi and exhibit the issue.
> > Even w/o my changes, forcing the .bss section to not be 8-byte aligned
> > in size causes the same issue.
> >
> > The underlying issue occurs due to calling stm32_dumpnvic from the
> > idletask with SYSLOG_TIMESTAMP enabled, but only when the Idlestak is
> > not aligned to an 8-byte bvoundary. The issue is due to invoking "x =
> > va_arg(ap, unsigned long long);" in vsprintf_internal
> > (lib_libvsprintf.c:1061) which aligns ap before accessing the long long:
> >
> > Breakpoint 5, vsprintf_internal (stream=stream@entry=0x20005390,
> > arglist=0x0,
> > numargs=0, fmt=0x8018bf2 ".%06ld] [%6s] %s: ",
> > fmt@entry=0x8005817 <lib_sprintf_internal+22> "...",
> > ap=..., ap@entry=..., numargs=0, arglist=0x0)
> > at stream/lib_libvsprintf.c:1061
> > 1061 x = va_arg(ap, unsigned long long);
> > p ap
> > $18 = {__ap =*0x2000536c*}
> > (gdb) x/5i $pc
> > => 0x800563a <vsprintf_internal+782>: add.w r9, r9, #7
> > 0x800563e <vsprintf_internal+786>:*bic.w r9, r9, #7 # align ap*
> > 0x8005642 <vsprintf_internal+790>: mov r7, r9
> > 0x8005644 <vsprintf_internal+792>: ldr.w r1, [r9, #4]
> > 0x8005648 <vsprintf_internal+796>: ldr.w r0, [r7], #8
> > (gdb) p/x $r9
> > $19 = 0x2000536c
> > (gdb) s
> > 1108 flags &= ~(FL_PLUS | FL_SPACE);
> > (gdb) p ap
> > $20 = {__ap =*0x20005378*}
> > (gdb) p/x $r7
> > $21 = 0x20005378
> > (gdb)
> >
> > This works fine if the stack is aligned on an 8-byte boundary (which all
> > other task/user stacks currently are due to MM_DEFAULT_ALIGNMENT being
> > 8). But if the idletask stack is not aligned, ap ends up incremented by
> > 12 causing access to any following vararg in vsprintf_internal to be
> > offset by 4 bytes resulting in potential exceptions.
> >
> > A fix is to increase the alignment in the .bss section to 8 in the
> > linker description file (since the idlestack immediately follows .bss
> > starting at _ebss). I've tested this fix on nucleo-743zi2 (based on
> > stm32h7), nucleo-h767zi (based on stm32f7), and nucleo-f446re (based on
> > stm32), all with success.
> >
> > I can provide a PR, but my question is whether this alignment should be
> > applied to all ARM?
> >
> > --
> > Peter Barada
> > [email protected]
> >
>
> Hi Peter,
>
> Good catch!!
>
> A PR would be very much appreciated.
>
> As for whether the alignment fix should be applied to all ARM, I don't know
> the answer off the top of my head, but I think it would be safe to do so.
>
> NuttX supports multiple ARM platforms, including:
>
> armv6-m
> armv7-a
> armv7-m
> armv7-r
> armv8-m
> armv8-r
> arm64
>
> The STM32H7 and STM32F7 both have a armv7-m core; without checking, I don't
> know which cores the other STM32 parts have.
>
> Since you caught this issue on armc7-m, I think it's safe to assume
> that armv7-a
> through arm64 probably require the stack aligned to 8 bytes.
>
> I don't know about armv6-m but I think it can be updated to 8-byte
> alignment as well, for consistency across the ARM platforms.
>
> In other words, Someone (tm) could go ahead and do the research to
> determine what the alignment requirements are for each of the cores listed
> above, or the alignment could just be updated to 8-byte whether it's needed
> or not.
>
> Thoughts?
>
> Nathan
>
