Luís Neto created an issue: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5270
## Summary A HardFault is consistently observed during application startup on the ATSAMV71 target when building and running the standard hello.exe sample from RTEMS 6.1. The fault occurs within the __libc_init_array function, indicating an issue with global static initialization. ## Target Hardware Details: **Processor Architecture:** `ARM Cortex-M7` **Chip Family/Model:** `ATSAMV711Q21` **Board Support Package (BSP):** `atsamv` (specifically, `arm/atsamv` as used in the sb-set-builder configuration) ## Build Environment: **OS:** Linux Ubuntu 22.04 LTS **RTEMS Source:** Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-6.1.tar.xz **RTEMS Source Builder:** Download from https://ftp.rtems.org/pub/rtems/releases/6/6.1/sources/rtems-source-builder-6.1.tar.xz ## Steps to reproduce ### 1. Build the RTEMS Toolchain using RSB: ``` ../source-builder/sb-set-builder --prefix=/home/ln/samv71/rtems/6.1 --target=rtems-arm --with-rtems-bsp=arm/atsam --with-rtems-tests=yes --with-rtems-bspopts="ATSAM_CHIP=samv71q21" 6/rtems-arm export PATH=/home/ln/samv71/rtems/6.1/bin:"$PATH" ``` ### 2. Build the RTEMS `hello.exe` Sample: ``` 1. ~/samv71/src/rtems-6.1$ ./waf bspdefaults --rtems-bsp=arm/atsamv > config.ini 2. ~/samv71/src/rtems-6.1$ ./waf clean 3. ~/samv71/src/rtems-6.1$ ./waf build 4. ~/samv71/src/rtems-6.1$ ./waf install 5. ~/samv71/src/rtems-6.1$ cp build/arm/atsamv/testsuites/samples/hello.exe build/arm/atsamv/testsuites/samples/hello.elf ``` ### 3. Run the `hello.exe` Application: Flash the eval board using `MPLAB X IDE v6.25`. ## Expected Behavior: The application should initialize successfully and print "Hello from RTEMS!" to the console. ## Actual Undesired Behavior: The application crashes with a HardFault immediately during startup. ## Crash Analysis: Upon inspecting the fault registers (captured from the HardFault handler), the following values were observed: **PC:** `0xFFFFFFFE` **LR:** `0x0040a5db` **SP:** `0x20404f28` **MMFSR:** `0x00000001` (IACCVIOL bit is set) **MMFARVALID:** 0 The **PC** = `0xFFFFFFFE` combined with **IACCVIOL** = 1 indicates an Instruction Access Violation, meaning the processor attempted to fetch and execute an instruction from an invalid memory address. Disassembly of `hello.exe` around the LR address (`0x0040a5db`) shows the context within `__libc_init_array`: ``` 0040a5a0 <__libc_init_array>: 40a5a0: 4b0f ldr r3, [pc, #60] @ (40a5e0 <__libc_init_array+0x40>) 40a5a2: b570 push {r4, r5, r6, lr} 40a5a4: 4d0f ldr r5, [pc, #60] @ (40a5e4 <__libc_init_array+0x44>) 40a5a6: 42ab cmp r3, r5 40a5a8: eba3 0605 sub.w r6, r3, r5 40a5ac: d007 beq.n 40a5be <__libc_init_array+0x1e> 40a5ae: 10b6 asrs r6, r6, #2 40a5b0: 2400 movs r4, #0 40a5b2: 3401 adds r4, #1 40a5b4: f855 3b04 ldr.w r3, [r5], #4 40a5b8: 4798 blx r3 40a5ba: 42a6 cmp r6, r4 40a5bc: d8f9 bhi.n 40a5b2 <__libc_init_array+0x12> 40a5be: 4d0a ldr r5, [pc, #40] @ (40a5e8 <__libc_init_array+0x48>) 40a5c0: f002 fa66 bl 40ca90 <_init> 40a5c4: 4b09 ldr r3, [pc, #36] @ (40a5ec <__libc_init_array+0x4c>) 40a5c6: 1b5e subs r6, r3, r5 40a5c8: 42ab cmp r3, r5 40a5ca: ea4f 06a6 mov.w r6, r6, asr #2 40a5ce: d006 beq.n 40a5de <__libc_init_array+0x3e> 40a5d0: 2400 movs r4, #0 40a5d2: 3401 adds r4, #1 40a5d4: f855 3b04 ldr.w r3, [r5], #4 40a5d8: 4798 blx r3 40a5da: 42a6 cmp r6, r4 40a5dc: d8f9 bhi.n 40a5d2 <__libc_init_array+0x32> 40a5de: bd70 pop {r4, r5, r6, pc} 40a5e0: 0040ea2c .word 0x0040ea2c 40a5e4: 0040ea2c .word 0x0040ea2c 40a5e8: 0040ea2c .word 0x0040ea2c 40a5ec: 0040ea30 .word 0x0040ea30 ``` At the point of crash: The `ldr.w r3, [r5], #4` instruction at `0x40a5d4` loads a value into `r3`. The `r5` value at crash (`0x0040ea30`) indicates that the load happened from `0x0040ea2c` (since `r5` is incremented by 4 after the load). The `objdump -s -j .init_array hello.exe` confirms the content at `0x40ea2c`: ``` Contents of section .init_array: 40ea2c ad044000 (Which, in little-endian, means 0x004004ad). ``` Therefore, the `blx r3` instruction at `0x40a5d8` attempts to jump to `0x004004ad`. Further `addr2line` reveals: `addr2line -e hello.exe 0x004004ad output: crtstuff.c:?` However, this entry contains the address `0x004004ad`, which is not a valid executable function pointer. Instead, it points to data or misaligned, non-executable bytes within the `frame_dummy` function (part of `crtstuff.c` and `libgcc`). Executing this address triggers the Instruction Access Violation. This indicates that a corrupted or incorrect address has been placed as the initial constructor entry in the `.init_array` section during the compilation and linking of the `hello.exe` sample. This suggests a potential issue within the RTEMS 6.1 toolchain components (specifically libgcc/Newlib's) for this target. -- View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/issues/5270 You're receiving this email because of your account on gitlab.rtems.org.
_______________________________________________ bugs mailing list [email protected] http://lists.rtems.org/mailman/listinfo/bugs
