SAM V71 Floating Point

[Günther (Gast)]

Hallo Leute!

Zu Testzwecken möchte ich meinen Atmel SAM V71 (ein Cortex-M7 mit FPU) 
eine Matrix mit "zufälligen" Floating-Point werten füllenlassen:

float32_t rnd_matrix[9];
  
for (uint16_t i = 0; i < 9; i++) {
  rnd_matrix[i] = (float32_t) rand();
}

Soweit funktioniert das auch alles. Möchte ich die Werte jedoch vorher 
skalieren, dann lande ich immer im Dummy Handler, d.h. es ist irgendeine 
Exception aufgetreten.

const float32_t scale = 10.5;
float32_t rnd_matrix[9];
  
for (uint16_t i = 0; i < 9; i++) {
  rnd_matrix[i] = (float32_t) rand() / scale;
}

Wobei ein üblicher Verdächtiger - die Division durch Null - hier 
natürlich ausgeschlossen werden kann.

Mein Ziel ist es eigentlich, kleine Float-Werte zwischen 0.0 und 1.0 mit 
der rand-Funtkionen zu bekommen und diese anschließend zu skalieren, 
damit sie zwischen 0.0 und 1.0 * scale liegen. Bspw. soll das dann so 
aussehen:

float scale = 10.0;
float random_f = (float)rand()/(float)(RAND_MAX/scale);

Leider ist das mein erster Ausflug in die Fließkomma-Welt, zuvor habe 
ich immer auf float oder double verzichtet und Integer genutzt. Deswegen 
kann ich mir den Fehler auch gerade nicht erkären ;)

Für einen Hinweis wäre ich sehr dankbar :)

[Günther (Gast)]

Kleine Ergänzung:

Es tritt obigem Code immer ein HardFault an der Stelle

rnd_matrix[i] = (float32_t) rand() / scale;

auf.

[Dennis R. (dennis_r93)]

Ich sehe auf dem ersten Blick auch keinen Grund warum der Code nicht 
funktionieren sollte.

Hast du in dem Dummy Handler mal nachgeschaut wie die Statusflags 
aussehen?
Ich habe es gerade nicht im Kopf, aber ich meine es gibt Statusflags, 
was genau passiert ist.
Wirft er die Exception bei der ersten Berechnung oder erst später?
Kannst du im Debuger im Singlestepmodus durchgehen und herausfinden bei 
welchem Befehl er die Exception wirft?

Es gibt auch Asynchrone Exceptions die erst viele Befehle später 
auftreten, Wenn du z.B. mit einem Store einen illegalen Zugriff machst 
wird die Exception nicht bei dem Store Befehl geworfen sondern erst 
später.
Deshalb wäre es interessant welche Exception geworfen wird.

[Dennis R. (dennis_r93)]

schau mal nach in
http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0646a/CIHFDJCA.html
Dort gibt es eine ganze Reihe Register die dir sagen können was schief 
gegangen ist.

[Jörg W. (dl8dtl) (Moderator)]

Meine Erfahrung mit den älteren SAMs (Cortex-M3/4): schalte mal alle
potenziellen Trap-Quellen explizit frei und installiere Handler
dafür, auf die du dann Breakpoints setzen kannst.

Das erspart dir den blöden "promotet hardfault", da es dir schneller
eine Indikation gibt, was wirklich schief gelaufen ist.

Prinzipiell kann man sich aucher auch beim promoted hardfault durch
die Registerbits hangeln um zu finden, was die konkrete Ursache war.

[Günther (Gast)]

So, eine kleine Rückmeldung:

Das Hard Fault Status Register (HFSR) hat das FORCED Bit gesetzt. Im 
Configurable Fault Status Register (CFSR) ist das Bit NOCP gesetzt. Die 
Beschreibung für dieses Bit lautet:

"The processor has attempted to access a coprocessor.

The processor does not support coprocessor instructions."

[klausr (Gast)]

Günther schrieb:
> The processor does not support coprocessor instructions."

Im Startup-Code FPU nicht aktiviert?

[Günther (Gast)]

Also ich habe in der main an erster Stelle einen Aufruf von

fpu_enable();

stehen. fpu_enable() ist wie folgt implementiert:

__always_inline static void fpu_enable(void)
{
  irqflags_t flags;
  flags = cpu_irq_save();
  REG_CPACR |=  (0xFu << 20);
  __DSB();
  __ISB();
  cpu_irq_restore(flags);
}

Muss die Aktivierung der FPU im Startup-Code erfolgen? Wenn ja, warum 
und woher bekomme ich diese Info?

[klausr (Gast)]

Günther schrieb:
> Muss die Aktivierung der FPU im Startup-Code erfolgen?

Nein, soweit ich weiß! Die FPU muss halt vor der Benutzung aktiviert 
werden.
Dein Startup Code sieht o.k. aus (nach 
http://www.atmel.com/Images/Atmel-44047-Cortex-M7-Microcontroller-Optimize-Usage-SAM-V71-V70-E70-S70-Architecture_Application-note.pdf 
S. 12). Da die SAM V71 noch relativ neu sind, könnte es auch ein Problem 
mit dem Compiler sein. Evtl. mal ein mini Programm schreiben, welches 
die FPU nutzt. Wenn das dann auch abstürzt, evtl. beim Support des 
Compiler-Herstellers nachfragen und genau alle Optionen angeben, die du 
beim Compilieren verwendet hast.

Anmerkung: Ich selbst habe keinen M7 geschweige denn einen SAM V71 hier.