Micro - STM32F437
Uses Micrium OS-III
The application compiles successfully on both versions of gcc; However, when I download and run the app I get a precise Bus Fault immediately where the BFAR points to some bizarre address (0x41980000)
For reference: I successfully compiled and ran the app without a fault 5-2016-q1, 7-2018-q2 and 8-2019-q3. The crash consistently happens with any version beyond that.
Below are the compiler options I use
arm-none-eabi-gcc -std=c11 -Wall -Werror -Wpedantic -pedantic -pedantic-errors -Wno-error=deprecated-declarations -Wlogical-op -Wswitch-default -Wdouble-promotion -Wunused -Wuninitialized -Wfloat-equal -Wredundant-decls -Wdate-time -Wextra -Wstrict-prototypes -Wshadow -ffunction-sections -fdata-sections -fno-builtin -ffreestanding -fstack-usage -fno-common -fdiagnostics-color=auto -fno-delete-null-pointer-checks -fsingle-precision-constant -funwind-tables -fomit-frame-pointer -D_XOPEN_SOURCE=700 -DNDEBUG -g -gdwarf-2 -gstrict-dwarf -Os -mthumb -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard
Is there something I am missing for the compiler options for 10-2020-q4 that could attribute to the error I am seeing?
Thank you
Hi there,Since you don't recognise the BFAR address of 0x41980000 as something to do with your setup, are you maybe able to identify what code was being run when the BusFault occured?
Hi
The app uses OS mem pool for allocating buffers for any message coming in through a CAN peripheral. The CAN library requires the app to pass a buffer to store the incoming message. The app acquires a buffer from the pool and passes it to the CAN library, The buffer has a valid address when it is acquired and passed along. However, when the message is being processed the pointer to the buffer has the faulty address (0x41980000). The fault occurs when the app tries to write something on the buffer. Few notes:Again, to reiterate - the code itself has remained the same throughout different versions of the compiler.
Another thing is that when this fault occurs, I am not getting the full callstack in the debugger - makes me think that the root cause of the problem may be different - just a thought. I just get the current function and the function that calls this function. There should at least be 3 more functions listed in the call stack based on the code flow.
The mem pool still has a lot more buffers remaining so it is not related to exhausted pool.
Micrium OS-III uses lazy stacking for floating point registers when switching task contexts. I saw some comments here and there about FP registers for newer versions. I am not sure if this has any bearing to what is happening.