06-24-2023 01:05 AM
I'm using the general use-case example by BSEC which I got from official github repository. My application project builds fine. As soon as I reach the first BSEC function (which is provided by the "libalgobsec.a" static library), program goes to hard fault interrupt handler.
My best guess would be that stack/heap size is insufficient. I have tried increasing both from 0x200 (heap) and 0x400 (stack) to 0x1000 (both) then also 0x8000 (both) through my linker file. However I see no difference - program hits the hard fault handler as soon as program enters the "bme68x_bsec_update_subscription" function.
It's also worth noting that I used proper "libalgobsec.a" static library - the one under Cortex-M7 folder (since my MCU uses this core)
Maybe there are other reasons I should consider in this case?
Under BSEC examples, I have found one Readme (in the appendix) file which states the algorithm inclusion process. I didn't follow the exact rules because (I think) they are meant for Arduino platform (and I'm using STM32 with PlatformIO in VS Code). However there are some flags that might be important and could affect this case. The only thing I did about compiler/linker flags is the inclusion of library libalgobsec.a" and provided flags for hardware floating point arithmetic.
I'm using STM32F756xx microcontroller in combination with CubeMX code generator (generates linker file where I can set stack/heap size).
06-24-2023 05:14 PM
Hi lgacnik97,
Did you use BSEC2.4.0.0?
We run latest BSEC2.4.0.0 on STM32F4(with CubeMX code generator) well. I can share my code to you if you need.
My modification in startup_stm32f401xe.s:
Stack_Size EQU 0x4000
Heap_Size EQU 0x4000
06-24-2023 05:28 PM - edited 06-24-2023 05:34 PM
Hello Robin,
Yes, the latest release, the BSEC 2.4.0.0. Note that I have posted in other question additional info, where I get hard fault because the "Undefined Instruction Set" even from the CFSR register. Besides the increased stack and heap size via linker script, I have ensured I'm using the `-mthumb` option for compiler, linker, and assembler, which uses the Thumb instruction set for CPU instructions - in case there is a problem with actual instruction set. Additionally, I have also tried the `-mthumb-interwork` option but the hard fault still happens. However, if I use `-marm` to use ARM instruction set, my code doesn't compile because CPU doesn't support this instruction set.
The modifications you used for stack and heap in the startup file I cannot use. It looks like I'm using a different instruction set? You can also share your code, maybe I find something myself.
I appended my startup and linker script.
06-24-2023 07:49 PM
I just found out something. Instead of libalgobsec.a from Cortex-M7 folder I took libalgobsec.a from Cortex-M4F folder. Now the application runs through bsec_update_subscription() where it initially failed. Now I also see why it happens this way - because I'm using compiler options -mfloat-abi=hard and -mfpu=fpv5-sp-d16. Now I see that there is no FPU support for Cortex-M7-based BSEC algorithm. However, if I use setting -mfloat-abi=soft the code doesn't compile. Any ideas? How do you compile on your machine using software floating point arithmetic?
06-24-2023 11:29 PM
Is it possible to use libalgobsec.a compiled static library for Cortex-M4 with FPU in with Cortex-M7 with CPU? If it compiles and builds without issues with the rest of the project, then I suppose it should be okay?