Introduction
Interrogizer is an Open Source project, aimed at providing developers with an affordable and easily producible tool to aid troubleshooting by enabling measurement of digital signals. Started from a desire to share hardware knowledge around Codethink, the device uses a small microcontroller placed on a simple PCB that can be easily and cheaply produced; allowing for iterations of the product as development progresses.
All information on what is required to build the hardware, software and instructions for use can be found on the project GitLab.
As Interrogizer is a board designed for debugging and prototyping, it provides access to different functionality via a simple interface:
- Low bandwidth (200kHz) logic analyser
- Host controlled GPIO (up to 16 pins)
A logic analyzer is a tool that is used to capture multiple time-varying signals from a digital circuit and then display them for analysis, to aid in developing or debugging digital systems.
Open logic analyzers are not a new thing, but what Interrogizer aims to do differently is to remain low cost, even at the expense of more advanced features. During firmware development there have been points where we could either optimize our approach or just upgrade the hardware to achieve similar results, however the latter way would have led to the overall cost rising.
Architecture
Hardware
Interrogizer is based around an STM32F072C8T6. This ARM Cortex M0 microcontroller is the highest priced part on the board; but at around £2.50 it still isn’t considered expensive.
The PCB was designed in the open source PCB design package KiCAD, a program that has seen a lot of development in recent years. KiCAD is a great way for both experienced and newcomers to create PCBs and with the advent of cheap PCB manufacturing it has massively lowered the barrier to entry for hobbyist projects.
It has a USB-B connector for host connection to the device, with a 20-pin output header with GND, 5V, 3.3V and 16 I/O pins broken out. The connectors, physical dimensions and LED placement are done in such a way that the board fits inside an existing off-the-shelf-enclosure that measures 102mm x 52mm x 26mm.
The input header is connected to two groups of pins on the STM32F07, and each of those groups is referred to as a port on the MCU. Port A is 3.3V tolerant as it is also shared with the internal ADC, and port B is 5V tolerant. Both ports are protected by an array of SRV05-4 rail clamps to provide overvoltage and ESD protection.
The remaining GPIO from the microcontroller is broken out to an internal header, primarily to allow for future use, but it’s something that has been helpful during firmware development so far.
There is, of course, an obligatory RGB LED to show device status - visible through the case!
Firmware
The firmware is based on LibOpenCM3 and revolves around the USB CDC connection to the host PC. Once the device has been enumerated, the host driver software will send commands to determine what function the device fulfills.
Currently that's only the Logic Analyser mode.
USB Commands are polled and each command is mapped to a corresponding function in the firmware.
Software
Interrogizer is being developed with the sigrok stack in mind. We have a development branch from the main trunk of libsigrok to add support for our device. The goal is that these changes will be upstreamed to sigrok.
- libsigrok is a shared library written in C, which provides the basic hardware access device drivers for logic analyzers, as well as input/output file format support.
- libsigrokdecode is a shared library written in C, which provides (streaming) protocol decoding functionality through protocol decoders written in python.
- sigrok-cli is a command-line frontend for sigrok.
- PulseView is a Qt-based logic analyzer and oscilloscope GUI for sigrok.
With support in libsigrok we are able to pipe our captured signals through the stack to be analysed and displayed using existing tooling.
Device Potential
As the firmware matures, and Interrogizer is put to use we can be begin to realise what other functionality can be brought in. Despite its size and cost, the STM32F07 is a versatile and powerful MCU that we're currently not exercising to its full potential.
With hardware changes to the board to support it, the MCU is capable of CAN communication. This would open up the possibility of using Interrogizer on projects that require analyzing the communication networks in modern vehicles.
It would be great to get more speed out of the logic analyzer functionality via an increased sample rate. There are paths to investigate to further optimize the firmware for this; or the possibility of hardware changes to bring in a part capable of USB 2.0 communication.
There are many avenues that can be taken to further develop Interrogizer and our hope is that as these cover vastly different hardware and software approaches that it will appeal to a wide range of people who can contribute and help shape the future of the project.
Other Content
- Codethink has achieved ISO 9001:2015 accreditation
- Outreachy internship: Improving end-to-end testing for GNOME
- Lessons learnt from building a distributed system in Rust
- FOSDEM 2024
- Introducing Web UI QAnvas and new features of Quality Assurance Daemon
- Outreachy: Supporting the open source community through mentorship programmes
- Using Git LFS and fast-import together
- Testing in a Box: Streamlining Embedded Systems Testing
- SDV Europe: What Codethink has planned
- How do Hardware Security Modules impact the automotive sector? The final blog in a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part two of a three part discussion
- How do Hardware Security Modules impact the automotive sector? Part one of a three part discussion
- Automated Kernel Testing on RISC-V Hardware
- Automated end-to-end testing for Android Automotive on Hardware
- GUADEC 2023
- Embedded Open Source Summit 2023
- RISC-V: Exploring a Bug in Stack Unwinding
- Adding RISC-V Vector Cryptography Extension support to QEMU
- Introducing Our New Open-Source Tool: Quality Assurance Daemon
- Long Term Maintainability
- FOSDEM 2023
- Think before you Pip
- BuildStream 2.0 is here, just in time for the holidays!
- A Valuable & Comprehensive Firmware Code Review by Codethink
- GNOME OS & Atomic Upgrades on the PinePhone
- Flathub-Codethink Collaboration
- Codethink proudly sponsors GUADEC 2022
- Tracking Down an Obscure Reproducibility Bug in glibc
- Web app test automation with `cdt`
- FOSDEM Testing and Automation talk
- Protecting your project from dependency access problems
- Porting GNOME OS to Microchip's PolarFire Icicle Kit
- YAML Schemas: Validating Data without Writing Code
- Deterministic Construction Service
- Codethink becomes a Microchip Design Partner
- Hamsa: Using an NVIDIA Jetson Development Kit to create a fully open-source Robot Nano Hand
- Using STPA with software-intensive systems
- Codethink achieves ISO 26262 ASIL D Tool Certification
- RISC-V: running GNOME OS on SiFive hardware for the first time
- Automated Linux kernel testing
- Native compilation on Arm servers is so much faster now
- Higher quality of FOSS: How we are helping GNOME to improve their test pipeline
- RISC-V: A Small Hardware Project
- Why aligning with open source mainline is the way to go
- Build Meetup 2021: The BuildTeam Community Event
- A new approach to software safety
- Does the "Hypocrite Commits" incident prove that Linux is unsafe?
- ABI Stability in freedesktop-sdk
- Why your organisation needs to embrace working in the open-source ecosystem
- Full archive