QUERY · ISSUE

esp32: viper tests fail after a while

openby tveopened 2020-04-11updated 2020-04-13

port-esp32

If I execute a micropython/viper test on an esp32 in a loop it starts failing after a while (I started with a HW reset before this):

> while true; ./run-tests --device /dev/ttyUSB0 --target esp32 micropython/
viper_ptr32_load.py; end
pass  micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
1 tests passed
[...]
pass  micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
1 tests passed
FAIL  micropython/viper_ptr32_load.py
1 tests performed (4 individual testcases)
0 tests passed
1 tests failed: viper_ptr32_load
skip  micropython/viper_ptr32_load.py
0 tests performed (0 individual testcases)
0 tests passed
1 tests skipped: viper_ptr32_load

It takes less than a minute to get there. I noticed because running the full test suite shows this, e.g.:

> ./run-tests --device /dev/ttyUSB0 --target esp32 -d micropython
[...]
pass  micropython/viper_misc_intbig.py
pass  micropython/viper_ptr16_load.py
pass  micropython/viper_ptr16_store.py
pass  micropython/viper_ptr32_load.py
pass  micropython/viper_ptr32_store.py
FAIL  micropython/viper_ptr8_load.py
FAIL  micropython/viper_ptr8_store.py
FAIL  micropython/viper_subscr.py
FAIL  micropython/viper_try.py
FAIL  micropython/viper_types.py
FAIL  micropython/viper_with.py
65 tests performed (411 individual testcases)
59 tests passed
4 tests skipped: heap_locked heapalloc_bytesio2 meminfo memstats
6 tests failed: viper_ptr8_load viper_ptr8_store viper_subscr viper_try viper_types viper_with

The tests that fail at the end are because they're at the end, not because they fail per-se.

CANDIDATE · ISSUE

esp32: `misc/rge_sm.py` test fails with hardware floating point enabled.

openby agattiopened 2025-05-25updated 2025-05-25

bug

Port, board and/or hardware

generic esp32 board with ESP32_GENERIC

MicroPython version

MicroPython v1.26.0-preview.148.g49f81d504.dirty on 2025-05-25; Generic ESP32 module with ESP32

Reproduction

Build the current master (49f81d5046aaeb31f90626426363ae2518dbd810) ESP32 port with hard floating point support enabled (force MICROPY_OBJ_REPR set to MICROPY_OBJ_REPR_C and MICROPY_FLOAT_IMPL set to MICROPY_FLOAT_IMPL_FLOAT)
Flash the firmware on the board and run the test suite
misc/rge_sm test will fail.

Expected behaviour

tests/misc/rge_sm.py should not fail with hard floating point support enabled.

Observed behaviour

The test output is attached:

misc_rge_sm.py.out.txt

Additional Information

Maybe the test should be rewritten using unittest.assertAlmostEqual to perform the value comparisons instead of relying on rounding behaviour.

I'm aware I'm trying out an uncommon object representation for the target in question, but I wonder if other MCUs with hardware floating point also exhibit the same test failure since the test relies on how float rounding is performed to pass.

Code of Conduct

Yes, I agree