-
Notifications
You must be signed in to change notification settings - Fork 2.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remote debug/test bench #26
Comments
@officialdarksheao What difference between Smoke and Integration/HW testing? |
For running unit tests (with Rust) in simple environments, we can also use avatar-rs. It allows to build code for x86, but execute all peripheral access operations on the device via SWD. Also FerrousSystems started developing something for unit-testing on the device itself. |
avatar-rs require svd2rust? |
@glitchcore it uses pac crates which are built with svd2rust, but doesn't use svd2rust directly iirc |
Is it possible to use JTAG instead of a control board to simulate button pushes and user I/O? I'm assuming the test host already has an ICD/programmer so it can flash the test builds. That would simplify the required hardware for setting up integration test hosts. |
I have no experience with using JTAG on STM32 as boundary scan and I found nothing in google about it. |
OpenOCD implements BS for STM32 and works with the cheap ST-Link debuggers. Writing to GPIO pins is possible. OpenOCD runs as a GDB server, but it also has a socket for accepting tcl commands. I'm thinking along the lines of a program that implements the same interface as the hardware emulator and spits tcl at openocd. The question I think is whether or not we can safely use JTAG BS without either upsetting some watchdog, throwing off timing, or upsetting OpenRTOS somehow. If the interface for the hardware emulator is written down somewhere I could go off and experiment. |
What do you mean "hardware emulator"? Now we have some stubs for handling GPIO, UART, etc. operations. Big question — how to emulate interrupts. For example, could we change pin level from OpenOCD and trigger EXTI? |
"Hardware emulator" was the phrase used above, as the software sim that app developers can use if they don't have real hardware. It has some UI that sends commands (button presses) and gets back a display from some kind of re-hosted or re-targeted version of the device software. The API that the simulator would expose to this front end UI would be very similar to the API exposed by a "device adapter" used by integration tests. If the interface were made common, then you could theoretically run and debug integration tests without hardware, then swap out the hardware emulator with this openocd bridge that would run those same tests on actual hardware. This all kind of assumes integration tests are black-box style, where the surface area the tests have to work with is only what the user can do while operating the device. Again, based on quoted comment from @officialdarksheao above. One more benefit of using JTAG instead of a control board is that black-box becomes gray-box because your tests can now read/write static symbols in the code running on the device, in addition to being able to push its buttons and get serial output.
Since EXTI pin is GPIO, then I think it could. It's worth trying. |
Sounds cool! My point: using openocd instead of driving/scanning real signal is good if this method guarantee that we see and reproduce real state of device. |
Today I learned https://robotframework.org/ for IoT testing, and Renode for STM emulating |
I'll look into ROS, but from what I remember it would be a heavy dependency. pyOCD is almost exactly what I think we want here. The problem is that it only supports the ARM debug TAP, not the STM32 TAP which would let you observe/drive the MCU's pads without involving the CPU. Today I'm going to figure out if it's possible to add support for additional JTAG TAPs to pyOCD. |
@mbelt pay attention to my comment in emulator issue thread: #22 (comment) |
Hello, guys! I can create by myself testing tool for remote hardware debugging with following features (so here is my suggestions):
I guess, that main control part of tool (e.g. "control board") must be independent and accessed only via UART with simple single-line protocol, and connected to target with real hardware (wires, w/o JTAG/etc. But this do not excluded JTAG as addition). That's main idea. Some another abilities can be also realized:
I suggest to make functional prototype, and after it maybe we'll want to built a few upgraded tools like this. Questions:
|
Remark for RFID test. We can use relay and simulate card touching. https://vostnod.livejournal.com/75405.html if needed. We should have "clean firmware" and queue for developers tests (checks) for CI. I think "online Flipper" can be overkill feature, cause we don't know a number of active developers. Developers - first, brainstorming - next. But building firmware and unit test are needed. |
Cool example) I'm afraid it not be applicable to NFC card due to high working frequency.
It is very useful to debug code on real hardware if you have not developer kit. |
I didn't use NFC. The main idea not to do unuseful features. Read "Getting real" book. So, lets solve only main problems. Online Flipper can be only "hipe" feature. I dont know development shedulers... I see supercomputer queue. I think its uncompatible with your goals. The simplest way to send development Flippers or use development boards. |
We don't have enough kits for everyone, and new contributors may want to work right now and don't wait when devboard come to them
Yes it is.
Really? I think such remote bench will be funny. |
what dev board do we need to purchase? |
To some developers we will send F2B0C1.1 board for debugging |
Replaced by #96 |
We discuss integration tests and automated remote test bench here.
We have flipper board and control board (for example, Raspberry PI). How Rpi can interact with Flipper to perform tests? Also remote debugging tool will be heplful.
@lomalkin promise to write down his vision by end of this week.
The text was updated successfully, but these errors were encountered: