Hard Crash Report, Trinket MO 3V

[fourfathom]

CIRCUITPY.zip

Running simple loop, testing internal clock frequency with time.monotonic reports, and loop counter in to see how many main loop cycles per second. It ran for several hours then crashed.

Also put in the busio.UART initialization, but not doing anything with it yet.

Some unused variables left over from previous testing.

[tannewt]

How did you have it powered? Have you managed to crash it more than once? Thanks!

[sommersoft]

It ran for several hours then crashed.

What was the Traceback or exception of the crash?

My initial thoughts point to your use of int(time.monotonic()). time.monotonic is a float, and the non-express boards (includes Trinket) don't have long int support. I would suspect you're hitting the upper limit of int when converting time.monotonic.

See Issue #572 for somewhat related discussion.

[fourfathom]

It was powered via my PC's USB2 port. and I was using Mu. It's possible that the connection was bumped -- the Trinket put up the crash report and asked me to post it here (so I did!) My apologies if it was just a power glitch.

I commented out the two UART lines, and ran it again overnight with no problem. I just un-commented them and am running it again.

As for int overflow, I don't think so. It's a 31-bit int (right?) and it should take over 34 years for a one-second increment to overflow a signed 31-bit int. I could pre-load that variable to test this, but it's not likely to be my problem.

I'm guessing power glitch, but I will report back in the re-run results.

Thanks for the advice, I've been programming for many years but am new to Arduino and Python.

[fourfathom]

Power glitch! I just bumped the connection and got the same crash. Here's the prompt:
`Auto-reload is on. Simply save files over USB to run them or enter REPL to disable.

You are running in safe mode which means something really bad happened.
Looks like our core CircuitPython code crashed hard. Whoops!
Please file an issue here with the contents of your CIRCUITPY drive:
https://github.com/adafruit/circuitpython/issues

Press any key to enter the REPL. Use CTRL-D to reload.

Adafruit CircuitPython 2.0.0 on 2017-09-12; Adafruit Trinket M0 with samd21e18

`
Hey, I was just following the instructions!

[tannewt]

@fourfathom Thanks for following the instructions!

It is interesting because we have a different message for when we think we reset due to power failure.

This message usually happens when a code error (like divide by zero or invalid memory access).

Mind trying with a different USB cable? I'm wondering if the USB code is getting funny data and crashing.

I'd love to fix the code issue its hitting but it can be a challenge to reproduce it on our end.

[fourfathom]

Happy to. I'm running it with the two lines of UART init code back in (my original code from my report) and am seeing crashes, but different, more like a regular power-fail then restart. I am using Putty for my"print" monitoring and it loses connection. When I reconnect the my code is running, but the count indicates that it restart from zero.

I will use a different cable and revert to Mu: the same configuration as in my report.

[fourfathom]

Probably unrelated, but this is puzzling me. In my main loop, I copy the time.monotonic() value to the variable mono_time. I save the int value of mono_time to new_time, and compare that to the previously saved int current_time, waiting for a new second. At the new second, I print the values of current_time (an int) and mono_time (a float), and a loop counter that tells me how many times the main loop cycles in the previous second.

Look at the results. The float to int conversion seems erratic when the float value fraction is approaching 1. For example, the first line in my output snippet shows that 7818.999767 coerces to the int 7819. This doesn't affect the function of my code, so it's no big deal. Is this just an issue of base-2 float conversion to base-10 for printing?

while True:
    loop += 1
    mono_time = time.monotonic()
    new_time = int(mono_time)
    if (new_time != current_time):
        led.value = 1
        current_time = new_time
        print("time: %i, %f, loop: %i" % (current_time, mono_time, loop))
        loop = 0
        led.value = 0
        #time.sleep(0.005)

time: 7819, 7818.999767, loop: 3450
time: 7820, 7819.999694, loop: 3451
time: 7821, 7821.000099, loop: 3450
time: 7822, 7822.000026, loop: 3451
time: 7823, 7822.999477, loop: 3451
time: 7824, 7823.999881, loop: 3450
time: 7825, 7825.000286, loop: 3450
time: 7826, 7825.999736, loop: 3451
time: 7827, 7826.999664, loop: 3451
time: 7828, 7828.000068, loop: 3451
time: 7829, 7828.999996, loop: 3450
time: 7830, 7829.999446, loop: 3451
time: 7831, 7830.999851, loop: 3450
time: 7832, 7832.000255, loop: 3451
time: 7833, 7833.000183, loop: 3451
time: 7834, 7833.999633, loop: 3451

[dhalbert]

Things like int(7818.999767) == 7819 are due to the limited precision of the 30-bit single-precision floats, and also how the number is formatted for printing. Upstream micropython has improved some formatting, which we haven't merged in yet -- I'm not sure if it fixes this.

This is an instructive online floating-point representation calculator: https://www.h-schmidt.net/FloatConverter/IEEE754.html.

[fourfathom]

Thanks for the floating point info. As I said, it's more of a curiosity than a problem

My overnight test again crashed, but apparently due to a lost USB serial port. When I woke up Mu had lost contact with the Trinket, and Windows Device Manager wasn't showing the com port. My code was still running (or had restarted), since the distinctive LED flash was active.

I suspect the particular USB port on the computer is the problem, and am now retrying it with different port, this time a USB-3 that seems more mechanically secure. I also clamped the new USB cable to the proto-board holding the Trinket, so there shouldn't be any bumped-connector problems.

[tannewt]

@fourfathom Please reopen if this happens with beta.1. It should go to a brownout specific safe mode now if it is a power issue. Thanks!