Serial Initialization in Dem Crashes on Nucleo STM32F030R8T6

[Giovanni]

USART 2 is wired to the ST-Link, you see it as an USB serial port.

Giovanni

[carldong]

Yes, it is connected as /dev/ttyACM0, but I don't get anything there. BTW, I just noticed that my title is wrong...

[Giovanni]

This strange, because USART2 is how I get the test report, is it possible there is a problem with the virtual com on Linux? could you make a test on a windows machine?

Giovanni

[carldong]

I did not set up anything on a Windows machine so I can't test for now... However, I tried standalone code before, both on this board and on a STM32F130RB Nucleo board, and those don't work either(on Linux).

[Giovanni]

Could you try another flavor of Linux from a CD? you just need to see if there is output.

Giovanni

[carldong]

I will try that.

[avshap]

Sorry for thread necromancy, but I have same problem (ChibiOS 16.1.5): STM32F0 demo hangs at USART initialization (gdb freeze at

Code: Select all

u->BRR = (uint32_t)(sdp->clock / config->speed);

) when compiled by Calculate Linux (Gentoo derivative) cross-compiler but works like a charm when compiled by Debian Unstable/Ubuntu 16.04 toolchain.

P.S. Copy of my arm-none-eabi-gcc -v output:

Code: Select all

COLLECT_GCC=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/4.9.4/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-none-eabi/4.9.4/lto-wrapper
Target: arm-none-eabi
Configured with: /var/calculate/tmp/portage/cross-arm-none-eabi/gcc-4.9.4/work/gcc-4.9.4/configure --host=x86_64-pc-linux-gnu --target=arm-none-eabi --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/arm-none-eabi/gcc-bin/4.9.4 --includedir=/usr/lib/gcc/arm-none-eabi/4.9.4/include --datadir=/usr/share/gcc-data/arm-none-eabi/4.9.4 --mandir=/usr/share/gcc-data/arm-none-eabi/4.9.4/man --infodir=/usr/share/gcc-data/arm-none-eabi/4.9.4/info --with-gxx-include-dir=/usr/lib/gcc/arm-none-eabi/4.9.4/include/g++-v4 --with-python-dir=/share/gcc-data/arm-none-eabi/4.9.4/python --enable-languages=c --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.9.4 p1.0, pie-0.6.4' --enable-poison-system-directories --disable-shared --disable-libatomic --disable-threads --without-headers --disable-bootstrap --with-newlib --enable-multilib --disable-altivec --disable-fixed-point --disable-libgcj --disable-libgomp --disable-libmudflap --disable-libssp --disable-libcilkrts --disable-vtable-verify --disable-libvtv --disable-libquadmath --enable-lto --without-cloog --disable-libsanitizer
Thread model: single
gcc version 4.9.4 (Gentoo 4.9.4 p1.0, pie-0.6.4)

P.P.S. Debug listings (*.map, and *.dmp) for NUCLEO-F030R8 demo (compiled with disabled optimization) are attached.

[Giovanni]

Hi,

It already happened that compilers included in distributions fail, those compilers are not really tested, just compiled from source IMHO.

I suggest you use this one: https://launchpad.net/gcc-arm-embedded

You can install it in any Linux flavor and it is known to work perfectly.

Giovanni