STM32: Division durch Null

[Walter T. (nicolas)]

Guten Morgen,

ich stehe gerade vor einem Rätsel. Ich wollte nur die Fehler-Ausgabe 
testen. Als praktischste Stelle kam mir ein Bresenham-Algorithmus vor, 
weil der häufig aufgerufen wurde.

    typedef struct State32_s
    {
        int32_t z;  /**< Zaehler */
        int32_t n;  /**< Nenner */
        int32_t r;  /**< Rest */
    }
    State32_t;

    State32_t GState = {.z = 300, .r = 0};

    static int32_t foo(void)
    {
        State32_t *State = &GState;
        
        int32_t dy = ((int64_t) State->z * dx + State->r)/State->n;
        State->r = ((int64_t) State->z * dx + State->r)%State->n;

        return dy;
    }

Mit dem Debugger habe ich State->n auf Null gesetzt. Von mir wurden auch 
keine extra Fehler-Handler als der HardFault_Handler() implementiert. 
Trotzdem wird diese Funktion mit State->n == 0 mehrmals durchlaufen, 
ohne dass ein Fehler auftritt. Der Rückgabewert wird auch weiter 
verwendet.

Was passiert hier?
Kann man in __eabi_ldivmod() irgendwie hineingucken?

[Ulf L. (ulf_l)]

welchen Wert hat denn dx und welcher Wert wird in dy zurück geliefert ?

[Walter T. (nicolas)]

Wenn dx = 29395, r = 0, ist dy = -1.

[. . (Gast)]

Walter T. schrieb:

> Mit dem Debugger habe ich State->n auf Null gesetzt. Von mir wurden auch
> keine extra Fehler-Handler als der HardFault_Handler() implementiert.
> Trotzdem wird diese Funktion mit State->n == 0 mehrmals durchlaufen,
> ohne dass ein Fehler auftritt. Der Rückgabewert wird auch weiter
> verwendet.
>
> Was passiert hier?

https://blog.feabhas.com/2013/02/developing-a-generic-hard-fault-handler-for-arm-cortex-m3cortex-m4/
Da steht: "To enable hardware reporting of div0 errors we need to 
configure the CCR"

[Ulf L. (ulf_l)]

Unabhängig von der fehlenden Error-Meldung:
Kann das der type-cast von 64Bit auf 32Bit sein ?
angenommen mit geteilt durch Null geht der 64Bit Wert auf den maximal 
positiven Wert
0X7FFF FFFF FFFF FFFF
wenn der cast daraus ein
0XFFFF FFFF
macht, käme -1 dabei heraus.

[Walter T. (nicolas)]

Das ließ sich ja einfach testen:

typedef struct State32_s
{
    int32_t z;  /**< Zaehler */
    int32_t n;  /**< Nenner */
    int32_t r;  /**< Rest */
}
State32_t;

State32_t GState = {.z = 300, .r = 0, .n = 0};


volatile int64_t temp = 0;

static int32_t foo(int32_t dx)
{
    State32_t *State = &GState;

    temp = ((int64_t) State->z * dx + State->r)/State->n;
    int32_t dy = temp;
    State->r = ((int64_t) State->z * dx + State->r)%State->n;

    return dy;
}


/* Funktion zum Testen von Sachen. */
exit_t runToShow(void)
{
    int32_t dx = 20000;
    volatile int32_t dy;

    dy = foo(dx);
    printf("dy = %i", dy);

    return EXIT_SUCCESS;
}

Ergebnis 1: Ja, Du hast Recht. Auf dem STM32 ist das tatsächlich ein von 
__eabi_ldivmod() bestmöglich behandelter Overflow.
temp = 0x7fffffffffffffff.

Ergebnis 2: Unter Windows (wo wahrscheinlich direkt die CPU den 
Divisionsbefehl bekommt) stürzt das wie erwartet gnadenlos ab.

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Aus dem ARM Infocenter:
Integer division is implemented by calling the C library functions 
__aeabi_idiv and __aeabi_uidiv. These check for divison by zero. If 
integer division by zero is detected, a branch to __aeabi_idiv0 is made. 
So to trap the division by zero, all you need to do is place a 
breakpoint on __aeabi_idiv0.

Also für die 64Bit Version das Symbol im Linkerscript ersetzen und dann 
einen Hardfault selber aufrufen?

Ein 64Bit div kann der 32Bit ARM Kern ja nicht selber ausführen.
Aber wieso bläst du da auf 64Bit auf?
Der Bresenham ist ja zum Linien zeichnen auf Rastern für eine GUI oder?
Das wird dann ja recht langsam in Software.

Ansonsten hat ein gast schon geschrieben, dass auch das 32Bit HW Div0 
Trap erst aktiviert werden muss.
Weiteres hier dazu: Beitrag "ARM Cortex-M3/4/7 Faulthandler"

[Walter T. (nicolas)]

Mw E. schrieb:
> So to trap the division by zero, all you need to do is place a
> breakpoint on __aeabi_idiv0.

Danke für den interessanten Aspekt.

Meine naive Frage: Wie setzt man denn einen Breakpoint in eine 
Library-Funktion mit einem grafischen Debugger? Mein erster Ansatz: 
Map-File aufrufen, nach der Funktion suchen und an die Adresse springen. 
(Erst einmal: Super, das das geht. Ein für mich neues und praktisches 
Hilfsmittel.) Geht es noch einfacher?

[Mw E. (Firma: fritzler-avr.de) (fritzler)]

Kann der denn nicht dein Disasm des Projekts aufrufen und darin 
breakpoints setzen?

Ansonsten eben die Symbolersetzung per Linkerscript gegen eine Funktion 
die nur "bkpt #0" enthält".