Open t-moe opened 5 months ago
Sorry for the late replay, i had a first go with the latest version of your probe-rs PR.
On top of your work i want to investigate what exactly and why the semihosting 0x15 is emitted and if it currently actually contains arguments. 0x15 should be argc argv command line parameter injected and i see them currently on every test run. ( If it works and also on a per test basis this could be quite handy)
For your testing do you read in parallel the uart console while connecting via jtag? (regarding the guru meditation error in the end)
Regarding the executor, the provided block_on method would provide a simple solution, so its definitely an option, though in the end it would be nicer if we maybe just allow a more generalized version to work ( maybe coupled with the "std" feature)
We may also want to integrate a panic_hook automatically on the "std" feature similar on how the panic_handler is provided in the no_std case.
For me stuff to work on
fix my current testcases where i got panics instead of errors returned in some cases
CONFIG_ESP_DEBUG_OCDAWARE
configThank you for responding, @Vollbrecht.
I wanted to inform you that I have reverted to using esp-hal for my project. In my opinion, esp-idf-* is too unstable. As a result, the development pace of embedded-test's support for esp-idf will be somewhat slower. Nonetheless, I am willing to assist with any issues you encounter to ensure it remains functional for your needs.
On top of your work i want to investigate what exactly and why the semihosting 0x15 is emitted and if it currently actually contains arguments. 0x15 should be argc argv command line parameter injected and i see them currently on every test run.
SYS_GET_CMDLINE
(0x15
) is used by embedded test. The target asks probe-rs which action it should run via SYS_GET_CMDLINE
. Either the targets has to print all available test (via semihosting 0x100
) or it has to run the test indicated by the given name. Did you encounter any problems with this syscall?
( If it works and also on a per test basis this could be quite handy)
What would you like to signal to the test? What usecase do you have in mind? I can see that this can be useful if you want to run a single test, but if you want to run the entire suite, how would you specify on a per-test basis what you want to pass?
For your testing do you read in parallel the uart console while connecting via jtag? (regarding the guru meditation error in the end)
Yes. This is how I found out about it. Or more specifically: I disabled rtt printing alltogether and only used the uart console.
Regarding the executor, the provided block_on method would provide a simple solution, so its definitely an option, though in the end it would be nicer if we maybe just allow a more generalized version to work ( maybe coupled with the "std" feature)
We may also want to integrate a panic_hook automatically on the "std" feature similar on how the panic_handler is provided in the no_std case.
In my opinion it is hard to do a generic version that works with every executor, but I think adding a idf
feature which adds a panic_hook automatically and uses the "block_on
-executor" is feasible.
CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y
will cause the tests to hang forever. Even a simple, empty test.Guru Meditation Error: Core 0 panic'ed (Breakpoint). Exception was unhandled.
after probe-rs disconnects. Then the target reboots in a loop, even ifCONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT=n
CONFIG_ESP_DEBUG_OCDAWARE=y
default, which will cause esp-idf to set a breakpoint on panic...I'll add more points as I go ahead with testing on esp-idf-*
(@Vollbrecht )