Cortex M4 App Crashes when moving from arm-none-eabi-gcc 8-2019-q3 to 10-2020-q4 major

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. 

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.