Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cpu/stm32: some tests are failing on CM33 (l5, u5) #17439

Open
aabadie opened this issue Dec 23, 2021 · 1 comment
Open

cpu/stm32: some tests are failing on CM33 (l5, u5) #17439

aabadie opened this issue Dec 23, 2021 · 1 comment
Assignees
Labels
Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Comments

@aabadie
Copy link
Contributor

aabadie commented Dec 23, 2021

Description

As reported in #17410 (see #17410 (comment)), some tests are failing on stm32l5 (and on stm32u5):

tests/malloc
Allocated 128 Bytes at 0x0x200bf880, total 697536
Allocated 128 Bytes at 0x0x200bf918, total 697672
Allocated 128 Bytes at 0x0x200bf9b0, total 697808
Allocated 128 Bytes at 0x0x200bfa48, total 697944
Allocated 128 Bytes at 0x0x200bfae0, total 698080
Allocated 128 Bytes at 0x0x200bfb78, total 698216
Allocated 128 Bytes at 0x0x200bfc10, total 698352
Allocated 128 Bytes at 0x0x200bfca8, total 698488
Allocated 128 Bytes at 0x0x200bfd40, total 698624
Allocated 128 Bytes at 0x0x200bfdd8, total 698760
Allocated 128 Bytes at 0x0x200bfe70, total 698896
Allocated 128 Bytes at 0x0x200bff08, total 699032

Context before hardfault:
   r0: 0xffffffff
   r1: 0x200c0020
   r2: 0x0000000c
   r3: 0x00000000
  r12: 0x080023ef
   lr: 0x080014c7
   pc: 0x08001536
  psr: 0x61000000

FSR/FAR:
 CFSR: 0x00008200
 HFSR: 0x40000000
 DFSR: 0x0000000b
 AFSR: 0x00000000
 BFAR: 0x00000000
Misc
EXC_RET: 0xffffffbc
Active thread: 1 "main"
Attempting to reconstruct state for debugging...
In GDB:
  set $pc=0x8001536
  frame 0
  bt

ISR stack overflowed by at least 16 bytes.
^C
tests/malloc_thread_safety
START
main(): This is RIOT! (Version: 2022.01-devel-1317-g5674d-pr/cpu/stm32u5)
Test Application for multithreaded use of malloc()
==================================================

This test will run duelling threads allocating and freeing memory.
The running thread is interrupted every millisecond and the other
threads gets scheduled. Eventually, this should yield to memory
corruption unless proper guards are in place preventing them. After
ca. two seconds without crash, the test is considered as passing.

Testing: malloc()/free()
Stack pointer corrupted, reset to top of stack
FSR/FAR:
 CFSR: 0x00008200
 HFSR: 0x40000000
 DFSR: 0x0000000b
 AFSR: 0x00000000
 BFAR: 0x00000004
Misc
EXC_RET: 0xffffffb0
Timeout in expect script at "child.expect("TEST PASSED")" (tests/malloc_thread_safety/tests/01-run.py:16)


tests/pthread_rwlock
main(): This is RIOT! (Version: 2022.01-devel-1317-g5674d-pr/cpu/stm32u5)
START
start
d2 (prio=8): sleep for    69522 µs.
start
d3 (prio=8): sleep for    95682 µs.
start
start
start
start
start
start
r2 (prio=8): 0: read  <-  0 (correct = 1)
d2 (prio=8): sleep for    80836 µs.
r3 (prio=8): 0: read  <-  0 (correct = 1)
d3 (prio=8): sleep for    20228 µs.
d7 (prio=8): sleep for   279012 µs.
w7 (prio=8): 0: write ->  1 (correct = 1)
d7 (prio=8): sleep for    42710 µs.
d3 (prio=8): sleep for    72654 µs.
d2 (prio=8): sleep for    52937 µs.
d4 (prio=9): sleep for    28038 µs.
d5 (prio=9): sleep for    25251 µs.
d6 (prio=9): sleep for    20994 µs.
r6 (prio=9): 0: read  <-  1 (correct = 1)
d6 (prio=9): sleep for    97095 µs.
r4 (prio=9): 0: read  <-  1 (correct = 1)
d4 (prio=9): sleep for    18099 µs.
r5 (prio=9): 0: read  <-  1 (correct = 1)
d5 (prio=9): sleep for     7884 µs.
r2 (prio=8): 1: read  <-  1 (correct = 1)
d2 (prio=8): sleep for    25930 µs.
r3 (prio=8): 1: read  <-  1 (correct = 1)
d3 (prio=8): sleep for    43392 µs.
d7 (prio=8): sleep for   278259 µs.
w7 (prio=8): 1: write ->  2 (correct = 1)
d7 (prio=8): sleep for   123248 µs.
d2 (prio=8): sleep for    55317 µs.
d3 (prio=8): sleep for    46098 µs.
r3 (prio=8): 2: read  <-  2 (correct = 1)
d3 (prio=8): sleep for    78386 µs.
r2 (prio=8): 2: read  <-  2 (correct = 1)
d2 (prio=8): sleep for    55048 µs.
d8 (prio=9): sleep for   167181 µs.
w8 (prio=9): 0: write ->  3 (correct = 1)
d2 (prio=8): sleep for    23545 µs.
d8 (prio=9): sleep for    92530 µs.
r2 (prio=8): 3: read  <-  3 (correct = 1)
d2 (prio=8): sleep for    88291 µs.
d7 (prio=8): sleep for   109749 µs.
w7 (prio=8): 2: write ->  4 (correct = 1)
d7 (prio=8): sleep for   194090 µs.
d3 (prio=8): sleep for    87987 µs.
d2 (prio=8): sleep for     5106 µs.
r2 (prio=8): 4: read  <-  4 (correct = 1)
d2 (prio=8): sleep for    38803 µs.
done
Stack pointer corrupted, reset to top of stack
FSR/FAR:
 CFSR: 0x00008200
 HFSR: 0x40000000
 DFSR: 0x0000000b
 AFSR: 0x00000000
 BFAR: 0x00000004
Misc
EXC_RET: 0xffffffb0
Timeout in expect script at "child.expect('done')" (tests/pthread_rwlock/tests/01-run.py:13)
tests/sys_sema_inv
START
main(): This is RIOT! (Version: 2022.01-devel-1317-g5674d-pr/cpu/stm32u5)
counter mode
THREAD 1 start
THREAD 2 start
THREAD 3 start
Stack pointer corrupted, reset to top of stack
FSR/FAR:
 CFSR: 0x00008200
 HFSR: 0x40000000
 DFSR: 0x0000000b
 AFSR: 0x00000000
 BFAR: 0x00000004
Misc
EXC_RET: 0xffffffb0
Timeout in expect script at "child.expect_exact('thread synced')" (tests/sys_sema_inv/tests/01-run.py:12)

tests/malloc works when the firmware is built with GCC 9.

Steps to reproduce the issue

make BOARD=nucleo-l552ze-q -C flash test

Expected results

The tests pass

Actual results

The tests fail (see details above)

Versions

Operating System Environment
----------------------------
         Operating System: "Ubuntu" "21.10 (Impish Indri)"
                   Kernel: Linux 5.13.0-22-generic x86_64 x86_64
             System shell: /usr/bin/dash (probably dash)
             make's shell: /usr/bin/dash (probably dash)

Installed compiler toolchains
-----------------------------
               native gcc: gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0
        arm-none-eabi-gcc: arm-none-eabi-gcc (GNU Arm Embedded Toolchain 10.3-2021.10) 10.3.1 20210824 (release)
                  avr-gcc: avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.2_1759) 5.4.0
         mips-mti-elf-gcc: mips-mti-elf-gcc (Codescape GNU Tools 2016.05-03 for MIPS MTI Bare Metal) 4.9.2
           msp430-elf-gcc: missing
       riscv-none-elf-gcc: missing
  riscv64-unknown-elf-gcc: missing
     riscv-none-embed-gcc: riscv-none-embed-gcc (xPack GNU RISC-V Embedded GCC, 64-bit) 10.1.0
     xtensa-esp32-elf-gcc: missing
   xtensa-esp8266-elf-gcc: missing
                    clang: Ubuntu clang version 13.0.0-2

Installed compiler libs
-----------------------
     arm-none-eabi-newlib: "4.1.0"
      mips-mti-elf-newlib: "2.1.0"
        msp430-elf-newlib: missing
    riscv-none-elf-newlib: missing
riscv64-unknown-elf-newlib: missing
  riscv-none-embed-newlib: "3.2.0"
  xtensa-esp32-elf-newlib: missing
xtensa-esp8266-elf-newlib: missing
                 avr-libc: "2.0.0" ("20150208")

Installed development tools
---------------------------
                   ccache: ccache version 4.2.1
                    cmake: cmake version 3.20.0
                 cppcheck: Cppcheck 2.3
                  doxygen: 1.9.1
                      git: git version 2.32.0
                     make: GNU Make 4.3
                  openocd: Open On-Chip Debugger 0.11.0+dev-00546-g5795f4d3e (2021-12-23-10:48)
                   python: Python 3.9.7
                  python2: Python 2.7.18
                  python3: Python 3.9.7
                   flake8: 3.9.2 (mccabe: 0.6.1, pycodestyle: 2.7.0, pyflakes: 2.3.1) CPython 3.9.7 on
               coccinelle: spatch version 1.1.0 compiled with OCaml version 4.11.1

@aabadie aabadie changed the title cortexm33: some tests are failing on stm32l5 cpu/stm32: some tests are failing on CM33 (l5, u5) Jan 3, 2022
@aabadie
Copy link
Contributor Author

aabadie commented Jan 3, 2022

The problem seems to only happen on STM32, so I updated the title of this issue.

@aabadie aabadie added the Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors) label Jan 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Development

No branches or pull requests

1 participant