Problems Compiling Particle Firmware

I’m trying to compile the device firmware having cloned it from github and checked out branch (v0.6.2) targeting PLATFORM=photon, however I’m getting a compile error:

/usr/arm-none-eabi/include/c++/6.3.1/mutex: In member function 'bool std::recursive_timed_mutex::_M_timedlock(const __gthread_time_t&)':
/usr/arm-none-eabi/include/c++/6.3.1/mutex:290:69: error: '__gthread_recursive_mutex_timedlock' was not declared in this scope
       { return !__gthread_recursive_mutex_timedlock(&_M_mutex, &__ts); }

I’m guessing it’s some kind of version conflict, as I’ve been using local compilation for a fair while, but I haven’t used it in the last year (maybe more).

I’ve actually had a previous warning/error as well which I mention in case it provides more evidence about the source of the problem. I fixed this issue by removing surplus braces (the while statement has a semi colon on the end of the line)
Error message:

MCU/STM32F2xx/SPARK_Firmware_Driver/src/system_stm32f2xx.c: In function 'SetSysClock':
MCU/STM32F2xx/SPARK_Firmware_Driver/src/system_stm32f2xx.c:394:5: error: this 'while' clause does not guard... [-Werror=misleading-indentation]
     while ((RCC->CFGR & (uint32_t)RCC_CFGR_SWS ) != RCC_CFGR_SWS_PLL);
     ^~~~~
MCU/STM32F2xx/SPARK_Firmware_Driver/src/system_stm32f2xx.c:395:5: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'while'
     {

Anyone got any pointers on what I need to upgrade, or where the issue lies?

Thanks,

Will.

Which folder and you compiling in?

2 Likes

I’m running
make clean all PLATFORM=photon
from the modules directory.

I’ve had five minutes to do some digging, still no solution, but trying to get more evidence as to what may be wrong.

Apparently gcc-arm-embedded needs to be 4.9.3 20150529 or above and I’m pretty sure it is, because when I run arm-none-eabi-gcc -v I get:

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/bin/../lib/gcc/arm-none-eabi/6.3.1/lto-wrapper
Target: arm-none-eabi
Configured with: /build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/src/gcc/configure --target=arm-none-eabi --prefix=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native --libexecdir=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/lib --infodir=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/share/doc/gcc-arm-none-eabi/info --mandir=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/share/doc/gcc-arm-none-eabi/man --htmldir=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/share/doc/gcc-arm-none-eabi/html --pdfdir=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/share/doc/gcc-arm-none-eabi/pdf --enable-languages=c,c++ --enable-plugins --disable-decimal-float --disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared --disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-newlib --with-headers=yes --with-python-dir=share/gcc-arm-none-eabi --with-sysroot=/build/gcc-arm-none-eabi-zabFqC/gcc-arm-none-eabi-6-2017q1/install-native/arm-none-eabi --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-pkgversion='GNU Tools for ARM Embedded Processors 6-2017-q2-update' --with-multilib-list=rmprofile
Thread model: single
gcc version 6.3.1 20170215 (release) [ARM/embedded-6-branch revision 245512] (GNU Tools for ARM Embedded Processors 6-2017-q2-update)

But I may be misreading the signs or confusing the package version with a file contained with in (though the date seems kind of a clue)?

The file being compiled seems to be:

platform/MCU/STM32F2xx/SPARK_Firmware_Driver/src/system_stm32f2xx.c

It doesn’t include the “mutex” file directly, so must be some intermediate. I’ll try and look at that chain when I next get time.

Any thoughts appreciated!

Apparently it’s a known issue using gcc6.

There’s a pull request that gives details, but there’s not a conclusive fix as others report more problems even after successful compilation.

Apparently firmware V 0.7.0rc1 will still target gcc5.3 - so if you want to compile the firmware, don’t upgrade!

Now I’ll have to look in to how to downgrade - another time!

W.

If you are on macOS or Linux you can use po-util to easily build and deploy firmware locally for all of Particle’s supported devices.