Zephyr: RV32M1 SPI loopback needs DEBUG_OPTIMIZATIONS

Created on 11 Nov 2019  Â·  4Comments  Â·  Source: zephyrproject-rtos/zephyr

Not enabling DEBUG_OPTIMIZATIONS in the spi_loopback test leads to reset loops in the code execution on RV32M1 / the vega board.
This was discovered while actually enabling the vegaboard for the spi loopback
https://github.com/zephyrproject-rtos/zephyr/pull/20428

To Reproduce
Take https://github.com/zephyrproject-rtos/zephyr/pull/20428 and remove CONFIG_DEBUG_OPTIMIZATIONS=y from the board config for the spi loopback test. This will work once, but a reset via the reset button will trigger a loop of aborted and restarted UART output.

Booting Zephyr OS build zephyr-v2.0.0-1813-gcbc791fdf249

Running test suite test_spi

starting test - testing_spi
I: SPI test on buffers TX/RX 0x2000004c/0x200003e0
I: Start
I: CS control inhibited (no GPIO device)� Booting Zephyr OS build zephyr-v2.0.0-1813-gcbc791fdf249

Running test suite test_spi

starting test - testing_spi
I: SPI test on buffers TX/RX 0x2000004c/0x200003e0
I: Start
I: CS control inhibited (no GPIO device)� Booting Zephyr OS build zephyr-v2.0.0-1813-gcbc791fdf249

Running test suite test_spi

starting test - testing_spi
I: SPI test on buffers TX/RX 0x2000004c/0x200003e0
I: Start
I: CS control inhibited (no GPIO device)� Booting Zephyr OS build zephyr-v2.0.0-1813-gcbc791fdf249
Running test suite test_spi

Expected behavior
No crash/restarts

Impact
This is limited to the spi_loopback sample on RV32M1 for now

Environment (please complete the following information):
Toolchain from open-isa.org

karsten@katzenklo:~/rv32m1/riscv32-unknown-elf-gcc/bin> ./riscv32-unknown-elf-gcc --version
riscv32-unknown-elf-gcc (GCC) 7.1.1 20170509

Additional context
Commenting out or shuffling around some of the tests will eventually start to a stable test execution, in particular the spi_complete_loop(spi_slow, &spi_cfg_slow) || spi_rx_half_start(spi_slow, &spi_cfg_slow) || spi_rx_half_end(spi_slow, &spi_cfg_slow) || spi_rx_every_4(spi_slow, &spi_cfg_slow) || spi_async_call(spi_slow, &spi_cfg_slow)) before spi_resource_lock_test blocks (for spi_slow and spi_fast) but that could be down to anything. Also the IRQ table seems to be generated correctly, all the pointers are valid and sensible

bug low

All 4 comments

Not so sure what my actual chances at finding the root cause of this are, I usually find issues around optimization flags to be awfully hard to isolate. But alas it sounds like a good opportunity to figure out how hardfault like handling on risc-v works :-)

With https://github.com/zephyrproject-rtos/zephyr/pull/26031 the crash/restart is fixed, but now the async nature seems to fail if the debug optimization level is disabled again.

> Running test suite test_spi

starting test - test_spi_loopback
I: SPI test on buffers TX/RX 0x20000074/0x200005b4
I: SPI test slow config
I: Start complete multiple
I: CS control inhibited (no GPIO device)
I: Passed
I: Start complete loop
I: Passed
I: Start null tx
E: Rx Buffer should contain NOP frames but got: 0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,
Assertion failed at /home/karsten/zephyrproject/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:266: spi_null_tx_buf: (1 is true)
Buffer not as expected

FAIL - test_spi_loopback

Test suite test_spi failed.

PROJECT EXECUTION FAILED
Assertion failed at /home/karsten/zephyrproject/zephyr/tests/drivers/spi/spi_loopback/src/spi.c:483: spi_async_call_cb: (ret is true)
one or more events are not ready

Ok found the root cause for the async fail and made PR #26032 for that. Together with PR #26031 this issue should be fixed.

Fixed by #26032 #26031 together. Thanks @karstenkoenig !

Was this page helpful?
0 / 5 - 0 ratings