sqrtf() ist immer 1 - STM32F401

[Martin K. (dschadu)]

Hi,

ich bin auf ein sehr seltsames Problem gestoßen:
In einem Minimal-Test Programm ist der Rückgabewert von sqrtf() immer 1. 
Identisch mit sqrt(). Egal was ich der Funktion an Wert übergebe 
(Variable oder Festwert).
Folgendes Setup:
GCC 12.3.1, cmake 3.20.3.2, STM32F401CCU6

Projekt erstellt mit VisualGDB und STM32CubeMX

Da der Code der main.c sehr lang ist, nur das was ich hinzugefügt habe 
zu der generierten Datei:

/* Private includes ----------------------------------------------------------*/
/* USER CODE BEGIN Includes */
#include <math.h>
/* USER CODE END Includes */

int main(void)
{
  // [Gekürzt]

  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  /* USER CODE BEGIN 2 */

  float x = 125;
  float y = 125;
  float xx = powf(x, 2);     // Ist korrekt: 15625
  float yy = powf(y, 2);     // Ist korrekt: 15625
  float xxyy = xx + yy;      // Ist korrekt: 31250
  float r0 = sqrtf(xxyy);    // Ist falsch: 1
  
  float r1 = r0 - 36;
  
  /* USER CODE END 2 */

  /* Infinite loop */
  /* USER CODE BEGIN WHILE */
  while (1)
  {
    /* USER CODE END WHILE */

    /* USER CODE BEGIN 3 */
  }
  /* USER CODE END 3 */
}

Ich habe schon versucht die Math-Library manuell dem Linker mit zu geben 
über die cmake. Und auch explizit die FPU deaktiviert. Beides brachte 
keinen Erfolg.

cmake_minimum_required(VERSION 3.15)

project(MathTest LANGUAGES C CXX ASM)

find_bsp(ID com.sysprogs.project_importers.stm32.cubemx SOURCE_PROJECT MathTest.ioc)

add_bsp_based_executable(NAME MathTest
  GENERATE_BIN
  GENERATE_MAP)

  target_link_libraries(MathTest PRIVATE m)
  target_compile_options(MathTest PRIVATE -mfloat-abi=soft)

Ich komm hier nicht mehr weiter und hoffe auf eure Hilfe.

[(prx) A. K. (prx)]

Versehentlich mit Optimierung übersetzt?

Keine der Variablen wird im gezeigten Code letztlich irgendwo genutzt. 
Kann dazu führen, dass sie verschwinden und die Rechnungen nicht 
durchgeführt werden.

Wer behauptet, der Wert sei -1?

[Martin K. (dschadu)]

Das ganze wird ohne Optimierung compiliert. Im Anhang ein Screenshot vom 
Debugging mit SWD.

Ich bin jetzt aber einen Schritt weiter: Es wird noch eine weiter cmake 
Datei eingebunden, mit den folgenden Flags:

set(_core_commonflags -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard)

Ändere ich -mfloat-abi=hard zu -mfloat-abi=soft, ist r0 = 1127270102. 
Immerhin nicht mehr 1, aber weit entfernt von richtig.

SystemInit wird auch korrekt aufgerufen, um die Hardware FPU zu 
aktivieren:

void SystemInit(void)
{
  /* FPU settings ------------------------------------------------------------*/
  #if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
    SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2));  /* set CP10 and CP11 Full Access */
  #endif
// [Gekürzt]
}

[Peter (pittyj)]

Warum steht eigentlich ein $ in dem Bild vor r0?

Kann es sein, dass der Debugger einfach nur das CPU Register r0 ausgibt, 
und nicht den Inhalt einer Variablen, die auch zufällig r0 heisst?

[Veit D. (devil-elec)]

Hallo,

online funktioniert das. Seltsam.

https://wandbox.org/permlink/28qJid5EviN5CygA

https://godbolt.org/z/cYGqYd5zr

[Martin K. (dschadu)]

Vielen dank für eure Hilfe schon einmal!
Ich habe ein Minimalprojekt identisch zu dem in VisualGDB einmal mit der 
STM32CubeIDE erstellt. Damit geht das problemlos (Auch mit Hardware 
FPU). Ich vermute hier also eine falsche Einstellung irgendwo in den 
Tiefen der cmake-files in Zusammenhang mit der Hardware FPU. Ich melde 
mich, wenn ich eine Lösung gefunden habe.


Peter schrieb:
> Warum steht eigentlich ein $ in dem Bild vor r0?
Das ist eine gute Frage

Edit:
> Kann es sein, dass der Debugger einfach nur das CPU Register r0 ausgibt,
> und nicht den Inhalt einer Variablen, die auch zufällig r0 heisst?
Oh mein gott, das ist es! Da wäre ich ja im leben nicht drauf gekommen. 
Vielen vielen Dank für diesen Hinweis!
Habe meinen Fehler also die ganze Zeit an der falschen stelle gesucht, 
weil dass das erste "falsche" Ergebnis war in der Formel.

[Niklas G. (erlkoenig)]

Martin K. schrieb:
> Ändere ich -mfloat-abi=hard zu -mfloat-abi=soft

Macht wenig Sinn bei einem Prozessor mit FPU sofern du keine externen 
Bibliotheken einbindest (außer den Standard Bibliotheken), weil unnötig 
langsam.

Übergebe

-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard

an alle (!) Compiler-Aufrufe und den Linker-Aufruf (!). Prüfe ob das 
auch wirklich von CMake übergeben wird, und nicht noch von irgendwo 
anders her noch "soft" übergeben wird. Dann sollte es "einfach so" 
funktionieren. Der Rückgabewert wird dann aber nicht in r0 zurück 
gegeben, sondern im FPU Register s0 ¹. Funktioniert auch mit 
Optimierungen.

Das funktioniert so mit dem GCC-ARM-Embedded, welcher u.a. bei der 
STM32CubeIDE mitgeliefert wird, und auch einzeln hier bezogen werden 
kann:

https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads

Bei manchen anderen (alten) GCC Distributionen klappt es so nicht.

1: AAPCS 
https://github.com/ARM-software/abi-aa/blob/2a70c42d62e9c3eb5887fa50b71257f20daca6f9/aapcs32/aapcs32.rst#procedure-calling