ECompass debagging impossible.

[RGünt.1]

Hello,
can anyone tell me what I am doing wrong?

For example, I can't get app_mems.c (eCompass) to debug.
The debugger does not stop when I set a breakpoint on subsequent function calls because, for whatever reason, the “SensorReadRequest” always has the value 0.:

RTC_Handler(&msg_dat);

Accelero_Sensor_Handler(&msg_dat);

Gyro_Sensor_Handler(&msg_dat);

Magneto_Sensor_Handler(&msg_dat);

Humidity_Sensor_Handler(&msg_dat);

Temperature_Sensor_Handler(&msg_dat);

Pressure_Sensor_Handler(&msg_dat);

 

I also need direct access to the variable “heading”.

 

[Tesla DeLorean]

Perhaps instrument your code so you understand what's happening, and the internal dynamics.

Instrument Error_Handler() and HardFault_Handler() or anywhere it could get stuck or hung-up.

Disassemble what was built, make sure you understand what's in the image that's on the part and why it might not be getting to your break point.

Add more break points and instrumentation to understand where it does go, and how far it gets.

[RGünt.1]

Hello,

The debugger has never got stuck and has never hung up, at least not with this application.

The application works in release mode without problems only in debug mode the variable SensorReadRequest is not set to 1, so that the following functions are not called:
RTC_Handler(&msg_dat);
Accelero_Sensor_Handler(&msg_dat);
Gyro_Sensor_Handler(&msg_dat);
Magneto_Sensor_Handler(&msg_dat);

Humidity_Sensor_Handler(&msg_dat);
Temperature_Sensor_Handler(&msg_dat);
Pressure_Sensor_Handler(&msg_dat);

The function HAL_TIM_PeriodElapsedCallback is never called in debug mode, I assume that this is the reason for this.

void HAL_TIM_PeriodElapsedCallback(TIM_HandleTypeDef *htim)
{
if (htim->Instance == BSP_IP_TIM_HANDLE.Instance)
{
SensorReadRequest = 1;
}
}

If this is the case, then I ask myself: Why is this only the case in debug mode and what do I have to do so that this function is also called in debug mode?

Translated with DeepL.com (free version)

[Tesla DeLorean]

The debug build likely to have different levels of optimization, and symbolic / line data in the object files.

Make sure things changed in interrupt/callback context are volatile

Optimization may remove or move around code to acheive goals, debug mode is more likely to have a 1:1 relationship with the source. Failures more frequently occur the other way around.

You'd have to contrast the output of the builds, ie the code the MCU is actually running.

If SensorReadRequest is not getting set, likely not getting the interrupt/callback, or the instances mismatch.

Like I said instrumentation of this might help identify if it's getting there less invasively than stopping the entire MCU for you to inspect/react.

Dump the TIM settings in both cases, and compare and constrast. Interrupts at what rate? Debug build apt to be slower in execution.

It's going to start by you identifying what's different, and where it first diverges.