Hang when waking up on battery

[c3d]

Hang when waking up on battery

[c3d]

This is really super-weird. I get the exact same behaviour even I don't call the bid128_to_string call but replace it with a much simpler snprintf call:

    char buf[MAXBIDCHAR];
    uint32_t *ptr = (uint32_t *) #
    snprintf(buf, MAXBIDCHAR-1, "%04X-%04X-%04X-%04X", ptr[0], ptr[1], ptr[2], ptr[3]);

Works like a charm on USB, hangs as soon as on batter power, and one of the strings generated by that code is produced.

[c3d]

It looks like the problem goes away if I do not move the __bid128 functions to the QSPI

@@ -63,7 +63,6 @@ SECTIONS
     *(.rodata.bid_multipliers1_bid64)
     *(.rodata.bid_multipliers2_binary128)
 /* ===== Addition by c3d =================== */
-    *(.text.__bid128*)
     *(.fonts)
 /* ======================== */
     . = ALIGN(8);

So it looks like the problem derives from executing code from the QSPI.

[c3d]

Got a hang without waking off from power, right after flashing firmware.

Plugging USB back in got me out of the hang. The calculator was shut down, maybe because I had hit the off button.

[c3d]

Doing a few more experiments, I am quite puzzled by the observed behavior. It looks like some specific functions in the Intel Binary Decimal library are causing the issue, and that can be as simple as rendering a number to text.

Here is the behaviour that I observe reliably:

• Connected to USB power, everything runs fine. Notably, I can run 1 SIN and see a result show up on screen.

• If I switch to battery power, then I can do operations on integer numbers, including operations that are complex and take some time, like multiplying large numbers. For exmaple, I can type 3 128 ^ and evaluate that, and I get the result.

• However, as soon as I start using fractional numbers, things go south. For example, 1.2 3.4 * will hang

• The hang is a soft hang, which records key. For example, while hung, I can type 123 and then connect USB, and the 123 will show up on screen.

• It is sufficient to have any floating-point number on the stack to see the problem. For example, if one has typed 1.2 3.4 *, then the problem appears as soon as the calculator is on battery power.

• The number has to be a decimal128. If I type 1.2 3.4 and do not perform the computation, things are fine. In that case, the numbers are small enough to be stored as decimal32. However, multiplying them with the default 34 Precision will generate a decimal128, and that causes problem.

• It is sufficient and apparently necessary for the decimal128 to be displayed on stack. For example, if I type while on USB power 2 SIN, then enter a sequence 1 2 3 4 5 6 7 8 9 10 11 12, and then switch to battery power, the calculator behaves well until the SIN result shows up on screen. Then it hangs until plugged back on USB.

• It is not a matter of time of execution. I tested that with the two following programs:

« Ticks 1 10000 start next Ticks - Negate »
'Test' STO

« Ticks 1 100000 start next Ticks - Negate »
'Test2' STO

The first one executes in 76ms on USB, 199ms on battery. The second one is about 10 times longer. I can run both on battery reliably.

[c3d]

The problem persists if I replace the code to render decimal128 values with a straight call to bid128_to_string without the wrapping code to format it. Also with a very large target buffer (256 bytes), which should be more than enough, notably because in that case there are at most about 42 characters.

    // Align the value
    bid128 num = value();

    // Render in a separate buffer to avoid overflows
    char buf[MAXBIDCHAR];
    bid128_to_string(buf, &num.value);
    record(decimal128, "Render raw output [%s]", buf);

#if 0
    size_t sz = decimal_format(buf, sizeof(buf), r.editing());
    record(decimal128, "Render formatted output [%s]", buf);
#else
    size_t sz = strlen(buf);
#endif

    // And return it to the caller
    return r.put(buf, sz) ? sz : 0;
}