esp-idf-* related issues

[t-moe]

• Setting CONFIG_LOG_DEFAULT_LEVEL_VERBOSE=y will cause the tests to hang forever. Even a simple, empty test.
  • Probably a timing thing? (Bug in probe-rs test code?)
• The target reports Guru Meditation Error: Core 0 panic'ed (Breakpoint). Exception was unhandled. after probe-rs disconnects. Then the target reboots in a loop, even if CONFIG_ESP_SYSTEM_PANIC_PRINT_REBOOT=n
  • This will not cause incorrect test results and might not even be user visible, but still this is not nice.
• Not sure about whether we need to do something about the CONFIG_ESP_DEBUG_OCDAWARE=y default, which will cause esp-idf to set a breakpoint on panic...
• Not sure if we should add support for esp-idf executor (using block_on), as an alternative to the embassy executor.

I'll add more points as I go ahead with testing on esp-idf-*

(@Vollbrecht )

[Vollbrecht]

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

• 0x15
• fix my current testcases where i got panics instead of errors returned in some cases
• play around with the CONFIG_ESP_DEBUG_OCDAWARE config
• verify the verbose logging problem

[t-moe]

Thank 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.