STM32F429-DISCOVERY demo unhandled exception and state checker issue Topic is solved

[zmolnar]

Hello Everyone,

I try to run the demo provided for the discovery board, but I'm currently facing two problems:

1. The program ends up in unhandled exception vector when the USB cable is plugged in

Compiled with CH_DBG_ENABLE_TRACE=TRUE and -O0 I get the following result:

Code: Select all

(gdb) load
Loading section .vectors, size 0x1e0 lma 0x8000000
Loading section .text, size 0xf8dc lma 0x80001e0
Loading section .rodata, size 0x27c8 lma 0x800fabc
Loading section .data, size 0xd4 lma 0x8012284
Start address 0x80002b8, load size 74584
Transfer rate: 17 KB/sec, 8287 bytes/write.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
VectorFC () at ../../../os/common/startup/ARMCMx/compilers/GCC/vectors.S:767
767           bl          _unhandled_exception
(gdb) bt full
#0  VectorFC () at ../../../os/common/startup/ARMCMx/compilers/GCC/vectors.S:767
No locals.
#1  <signal handler called>
No symbol table info available.
#2  usb_lld_start_in (usbp=0x200008d8 <USBD2>, ep=0 '\000') at ../../../os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:1288
        isp = 0x20000950 <ep0_state.lto_priv>
#3  0x0800d218 in usbStartTransmitI (usbp=0x200008d8 <USBD2>, ep=0 '\000', buf=0x0, n=0) at ../../../os/hal/src/hal_usb.c:515
        isp = 0x20000950 <ep0_state.lto_priv>
        __func__ = <optimized out>
#4  0x0800d464 in _usb_ep0setup (usbp=0x200008d8 <USBD2>, ep=0 '\000') at ../../../os/hal/src/hal_usb.c:861
        max = 0
#5  0x0800dff8 in otg_epout_handler.lto_priv.437 (usbp=0x200008d8 <USBD2>, ep=0 '\000') at ../../../os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:429
        otgp = 0x40040000
        epint = 8
#6  0x0800bf0a in usb_lld_serve_interrupt (usbp=0x200008d8 <USBD2>) at ../../../os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:639
        otgp = 0x40040000
        sts = 524288
        src = 65536
#7  0x0800bfe8 in Vector174 () at ../../../os/hal/ports/STM32/LLD/OTGv1/hal_usb_lld.c:729
No locals.
#8  <signal handler called>
No symbol table info available.
#9  0x55555554 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) [dir=rtl][/dir]


2. When the code is compiled with CH_DBG_SYSTEM_STATE_CHECK=TRUE and -O0 the state checker stops the execution

Code: Select all

(gdb) load
Loading section .vectors, size 0x1e0 lma 0x8000000
Loading section .text, size 0xfd14 lma 0x80001e0
Loading section .rodata, size 0x2820 lma 0x800fef4
Loading section .data, size 0xd4 lma 0x8012714
Start address 0x80002b8, load size 75752
Transfer rate: 17 KB/sec, 7575 bytes/write.
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0800d2c0 in chSysHalt (reason=0x80126ec "SV#8") at ../../../os/rt/src/chsys.c:206
206     ch.dbg.panic_msg = reason;
(gdb) p ch.dbg.panic_msg
$1 = 0x80126ec "SV#8"
(gdb) bt full
#0  0x0800d2c0 in chSysHalt (reason=0x80126ec "SV#8") at ../../../os/rt/src/chsys.c:206
No locals.
#1  0x0800b19c in _dbg_check_enter_isr () at ../../../os/rt/src/chdebug.c:204
No locals.
#2  0x0800cc76 in VectorB0 () at ../../../os/hal/ports/STM32/LLD/TIMv1/hal_st_lld.c:255
No locals.
#3  <signal handler called>
No symbol table info available.
#4  0x55555554 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb)


I will start debugging as it is a good opportunity to dig deeper into the system, any help is warmly welcome. Thanks in advance!

EDIT:

ChibiOS version is:

Code: Select all

commit f28877c6aa3cdce70df027fb4872d7dde1c1a788 (HEAD -> master, origin/master, origin/HEAD)
Author: gdisirio <gdisirio@110e8d01-0319-4d1e-a829-52ad28d1bb01>
Date:   Sat Jul 7 14:00:37 2018 +0000

    Fixed an invalid path.
   
    git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@12141 110e8d01-0319-4d1e-a829-52ad28d1bb01

Zoltan

[Giovanni]

Hi,

Which version of ChibiOS?

Giovanni

[zmolnar]

Hi,

latest trunk from github:

commit f28877c6aa3cdce70df027fb4872d7dde1c1a788 (HEAD -> master, origin/master, origin/HEAD)
Author: gdisirio <gdisirio@110e8d01-0319-4d1e-a829-52ad28d1bb01>
Date: Sat Jul 7 14:00:37 2018 +0000

Fixed an invalid path.

git-svn-id: svn://svn.code.sf.net/p/chibios/svn/trunk@12141 110e8d01-0319-4d1e-a829-52ad28d1bb01

Zoltan

[Giovanni]

Moving in bug reports.

Giovanni

[zmolnar]

Can it happen that it is a toolchain related problem?

I use GCC 6.3.1 which has a known issue with LTO, so I disabled that in the Makefile. If I compile it with -O0 it produces the result mentioned in my first post. If I compile it with -O2 the program doesn't stuck in unhandled exception but runs fine, although data can not be transferred through the VCP. I can open the serial port with a terminal application but I can't send or receive anything, while the controller spins in the idle thread in turn.

Zoltan

[Giovanni]

It is possible, is it a self built compiler?

State checker should not be affected by compiler optimization level.

Giovanni

[zmolnar]

No, it is the official pre-built compiler taken from the ubuntu repository.

Code: Select all

arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:6.3.1+svn253039-1build1) 6.3.1 20170620
Copyright (C) 2016 Free Software Foundation, Inc.

Zoltan

[Giovanni]

Then it is very likely the compiler is your problem.

Use the compiler from here: https://launchpad.net/gcc-arm-embedded

This is "official" from ARM.

Giovanni

[zmolnar]

Hi Giovanni!

I can confirm that the compiler provided by ARM solved the problem, now the application runs fine, the VCP works as expected.

The state-checker issue is still present.

Thanks for your help, I really appreciate it!

Zoltan

[Giovanni]

I will look into the other issue.

Giovanni