Skip to main content
D
darkfader
Associate II
July 14, 2026
Solved

STM32F769 Linux Unhandled exception

  • July 14, 2026
  • 1 reply
  • 35 views

 

I’m working with my stm32f769-DISCOvery board.

I’m trying to work through a few things that are unfinished/missing with the various buildroot configs on github and the stock one in buildroot.

On boot, it crashes like this:

[    1.705669] Unhandled exception: IPSR = 00000006 LR = fffffffd
 

I’m apparently hitting an error with binutils newer than 2.28.1.

It’s looking like this report, except I have also managed to get fffffff1 instead of fffffffd

https://github.com/fdu/STM32F769I-disco_Buildroot/issues/1#issue-340504566

This emcraft patch seems to be intended to mitigate the crash:

https://github.com/EmcraftSystems/linux-upstream/commit/2882de1d86bd536c855feee582d44722434c2ac9

In theory, the fix should be upstream as as well, and the 5.15 kernel i’m playing with should be new enough. (I’ll need to validate that I guess)

https://github.com/torvalds/linux/commit/afc9f65e01cd114cb2cedf544d22239116ce0cc6

 

Looking at this:

https://github.com/fdu/STM32F769I-disco_Buildroot/issues/1

It seems it is caused by binutils 2.28.1. I’m sure I knew that, I can even find some post of mine that I have no recollection of ;-)

Anyway, this leads among other things to this LKML thread https://lkml.org/lkml/2018/6/19/917 and https://lkml.org/lkml/2018/6/19/927

 

What I’m not understanding is how this is not seen more commonly and what the common strategy is to deal with it. would it not affect most Cortex-M7/Thumb2 processors?

I see a few people have gone back to 2.28.1 binutils or patched 2.29 or patched parts of the kernel but I’m not sure why, or what, hasn’t been upstreamed.

 

debug info:

So, that’s what I put in buildroot. Flash the SD card, boot, and the kernel crashes with this instruction issue, see here:

 

Starting kernel ...

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 5.15.202 (demo@localhost.localdomain) (arm-buildroo
t-uclinux-uclibcgnueabihf-gcc.br_real (Buildroot 2024.05) 13.3.0, GNU ld (GNU Bi
nutils) 2.41) #1 PREEMPT Sun Jul 12 13:40:47 UTC 2026
[    0.000000] CPU: ARMv7-M [411fc270] revision 0 (ARMv7M), cr=00000000
[    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
[    0.000000] OF: fdt: Machine model: STMicroelectronics STM32F769-DISCO board


[snipsnap]

[    1.705669] 
[    1.705669] Unhandled exception: IPSR = 00000006 LR = fffffffd
[    1.712892] CPU: 0 PID: 40 Comm: rcS Not tainted 5.15.202 #1
[    1.718525] Hardware name: STM32 (Device Tree Support)
[    1.723648] PC is at 0xc061940a
[    1.726771] LR is at 0xc060ebd5
[    1.729895] pc : [<c061940a>]    lr : [<c060ebd5>]    psr: 81000000
[    1.736145] sp : c0668830  ip : 00000000  fp : 00000004
[    1.741353] r10: c066ac28  r9 : ffffffff  r8 : ffffffff
[    1.746561] r7 : c066b030  r6 : c066b0d0  r5 : c066b030  r4 : c066ac28
[    1.753070] r3 : c066ac48  r2 : 00000020  r1 : 00000020  r0 : c066b028
[    1.759581] xPSR: 81000000
[    1.762275] CPU: 0 PID: 40 Comm: rcS Not tainted 5.15.202 #1
[    1.767914] Hardware name: STM32 (Device Tree Support)
[    1.773055] [<c000afa5>] (unwind_backtrace) from [<c000a283>] (show_stack+0xb/0xc)
[    1.780597] [<c000a283>] (show_stack) from [<c000a8b3>] (__invalid_entry+0x4b/0x4c)
 

 

I have the following settings in buildroot

BR2_NORMALIZED_ARCH="arm"
BR2_ENDIAN="LITTLE"
BR2_GCC_TARGET_ABI="aapcs-linux"
BR2_GCC_TARGET_CPU="cortex-m7"
BR2_GCC_TARGET_FPU="fpv5-sp-d16"
BR2_GCC_TARGET_FLOAT_ABI="hard"
BR2_GCC_TARGET_MODE="thumb"
BR2_READELF_ARCH_NAME="ARM"
BR2_ARM_CPU_MAYBE_HAS_FPU=y
BR2_ARM_CPU_HAS_FPU=y
BR2_ARM_CPU_MAYBE_HAS_FPV4=y
BR2_ARM_CPU_HAS_FPV4=y
BR2_ARM_CPU_MAYBE_HAS_FPV5=y
BR2_ARM_CPU_HAS_FPV5=y
BR2_ARM_CPU_HAS_THUMB2=y
BR2_ARM_CPU_ARMV7M=y
 

i last worked on this a month ago, so I don’t recall all details but I went through the configure once more and looked it and all of it seems good. Meaning, from a lot of reading they should be correct. I tried a few attempts as well.

 

 

btw. it seems to only show if i enable the FPU (but: One thing that I really care about in terms of performance would be to have the FPU enabled in the kernel). I don’t know the assembler backgrounds for it (and can’t learn them currently)

I’ve just tried again, with no VFP and soft float the kernel is booting. But this macro they patch back (__badr) seems to not be a FPU instruction? (I’m not sure)

 

I understand the Cortex-M7 has an optional FPU. For all I know, the stm32f769 does have this FPU. I’ve seen example code for it. Further, as far as I understood, other from some M4 models, it has not a single but double-float-able FPU, so it should work for most random stuff thrown at it. As far as I understand it _also_ has the FPV5 extensions which make some extra operations avaliable (I forgot the details as to what, if it’s vector or simd or whatever. It’s something, and for the later M7 versions like this one is, it should be FPV5)

 

rationale for messing around with this:

I’d rather take the time to sort this out now and be able to work with a fairly recent buildroot. I wanna be able to contribute QSPI root support and try out XiP, break out the modules so they can be on disk instead of having a too large for the ram kernel image.

et cetera. many tiny steps, it’s possible to do and so i think it should be done. At the very least I need to make enough space to load the TFT framebuffer drivers and all that. I know basically this is an MCU and I should maybe not be using Linux when there’s more direct ways to the same goal. But it HAS 16MB ram. That’s more than enough to run Unix with GUI. Especially since today we have XiP so the RAM usage will be quite limited. plus, my ressources are limited as well, and sticking with buildroot/linux will pay forward on multiple other projects. When I can afford it again I’ll look at the emcraft package for this board, but right now it ‘s not possible. Also, emcraft didn’t enable the FPU in-kernel, just for userspace.

Best answer by mƎALLEm

Hello,

Better to ask the question to Emcarft or who developped that buildroot.

my question stays insofar as “how does anyone make ARM Cortex-M7 boot with FPU?”

You need to ensure CP10 and CP11 bits are set in SCB_CPACR register:

https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Address-Map/System-Control-Space--SCS-/Coprocessor-Access-Control-Register--CPACR

In the HAL implementation (system_stm32f7xx.c file) / almost after reset:

void SystemInit(void)
{
  /* FPU settings ------------------------------------------------------------*/
  #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
  #endif
..
..

Hope that helps.

1 reply

D
darkfaderAuthor
Associate II
July 14, 2026

what I found so far is that the added macro from https://lkml.org/lkml/2018/6/19/927 is missing in 5.15.211. i’ll add that back, although I do not understand what it does or why it is defined here in arch/arm/include/asm/assembler.h while most other things are in arch/arm/kernel/*.S.

edit: Adding the macro back didn’t help.

[    0.938741]     consoleblank=0
[    1.059257] EXT4-fs (mmcblk0p2): re-mounted. Opts: (null). Quota mode: disabled.
[    1.225429] 
[    1.225429] Unhandled exception: IPSR = 00000006 LR = fffffffd
[    1.232653] CPU: 0 PID: 40 Comm: rcS Not tainted 5.15.211 #1
[    1.238286] Hardware name: STM32 (Device Tree Support)
[    1.243410] PC is at 0xc07198dc
[    1.246531] LR is at 0xc070f891
[    1.249657] pc : [<c07198dc>]    lr : [<c070f891>]    psr: 81000000
[    1.255906] sp : c076a828  ip : 00000000  fp : 00000004
[    1.261113] r10: c04e8d20  r9 : ffffffff  r8 : ffffffff
[    1.266321] r7 : c04e9128  r6 : c04e91a8  r5 : c04e9128  r4 : c04e8d20
[    1.272831] r3 : c04e8d38  r2 : 00000018  r1 : 00000018  r0 : c04e9120
[    1.279341] xPSR: 81000000
[    1.282036] CPU: 0 PID: 40 Comm: rcS Not tainted 5.15.211 #1
[    1.287675] Hardware name: STM32 (Device Tree Support)
[    1.292815] [<c000b009>] (unwind_backtrace) from [<c000a2c3>] (show_stack+0xb/0xc)
[    1.300356] [<c000a2c3>] (show_stack) from [<c000a91f>] (__invalid_entry+0x4b/0x4c)
 

 

my question stays insofar as “how does anyone make ARM Cortex-M7 boot with FPU?” still is a question. What I see is a lot hinges on the kernel option CONFIG_THUMB2_KERNEL, whilst the issue in general is supposed to be in binutils. This is really confusing ;-)

mƎALLEm
mƎALLEmBest answer
ST Technical Moderator
July 14, 2026

Hello,

Better to ask the question to Emcarft or who developped that buildroot.

my question stays insofar as “how does anyone make ARM Cortex-M7 boot with FPU?”

You need to ensure CP10 and CP11 bits are set in SCB_CPACR register:

https://developer.arm.com/documentation/ddi0403/d/System-Level-Architecture/System-Address-Map/System-Control-Space--SCS-/Coprocessor-Access-Control-Register--CPACR

In the HAL implementation (system_stm32f7xx.c file) / almost after reset:

void SystemInit(void)
{
  /* FPU settings ------------------------------------------------------------*/
  #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
  #endif
..
..

Hope that helps.

To give better visibility on the answered topics, please click "Best answer" on the reply which solved your issue or answered your question.
    D
    darkfaderAuthor
    Associate II
    July 14, 2026

    Thank you!

    I see. So if the kernel doesn’t flip those two switches the FPU will be there, but not enabled.

    Then it could be true that it’s still “off” I got to try to boot with softfloat and later enable it, or look for a way to enable it when U-boot is loaded. I’ll ask emcraft next year when I can get their kit.

    knowing that they also don’t enable it in-kernel it’s plausible that it is “disabled” here.

     

    I did a quick search and it seems this will indeed be possible in U-boot.

    https://stackoverflow.com/questions/22705690/how-to-set-the-socs-register-values-in-linux-kernel-and-u-boot

     

    I take it the FPU stays on till power cycle?

    Terms & ConditionsAccessibility statement