Enabling FPU causes device to reboot

[IvanR]

I have this function that normalizes acceleration from IMU:

_Float16 normalize_accel_magnitude(_Float16 x, _Float16 y, _Float16 z, _Float16 max_g) {
  // Compute the magnitude squared of the acceleration vector
  _Float16 magnitude_squared = x * x + y * y + z * z;

  // Protect against very small values
  if (magnitude_squared < __FLT16_MIN__) {
    magnitude_squared = __FLT16_MIN__;
  }

  // Compute the magnitude of the acceleration vector
  _Float16 magnitude = sqrtf(magnitude_squared);

  // Normalize the magnitude using max_g
  if (max_g == 0.0f || fabs(max_g) < __FLT16_MIN__) {
    return 0.0f;
  }

  _Float16 normalized_value = (magnitude / max_g) - 1.0f;

  // Validate the normalized value
  if (!is_valid_float(normalized_value)) {
    return 0.0f;
  }

  return normalized_value;
}

If I enable FPU

CONFIG_FPU=y

CONFIG_FPU_SHARING=y

device works for a while (10s of seconds) then reboots, if its commented out it works fine ? the issue seams to be with 

sqrtf. 

Any ideas why enabling FPU would cause it?  Thanks!

[Susheel Nuguru]

Any ideas why enabling FPU would cause it?  Thanks!

It would be best to first understand the nature of the reboot. If it is a softreset, then you should be able to put a breakpoint in sys_reboot function, start the application in debugger and try to understand the context of this reboot. If it is hardfault then you should enable the more logs to catch some serial logs to get the nature of the hardfault. 

[IvanR]

CONFIG_LOG=y

gives no info. Which logs options should I enable?

[Susheel Nuguru]

Try this

# Debugging configuration
CONFIG_THREAD_NAME=y
CONFIG_THREAD_ANALYZER=y
CONFIG_THREAD_ANALYZER_AUTO=y
CONFIG_THREAD_ANALYZER_RUN_UNLOCKED=y
CONFIG_THREAD_ANALYZER_USE_PRINTK=y

# Add asserts
CONFIG_ASSERT=y
CONFIG_ASSERT_VERBOSE=y
CONFIG_ASSERT_NO_COND_INFO=n
CONFIG_ASSERT_NO_MSG_INFO=n
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_THREAD_NAME=y

Also try the breakpoint on sys_reboot and starting your program in the debug mode to attempt to hit the breakpoint and looking at the function call stack to understand the context of the reboots. We need to get the context of reboot one way or the other to get a proper debugging direction here.