For a project with one of our larger clients, Codethink engineers had been using a 3rd party debugging board, purchased by the customer. Engineers found that the debug board features were quite limited. Due to the delicate design of the board, the lead time for production was long and as a result, supplies were running out. It was clear that an alternative solution was needed. There was a desire to be able to automate the changing of debug settings on the board. Previous boards were using manual switches to change debug and boot modes.
To address the deficiencies of the board used, Codethink engineers, with the trust of the client, developed their own bespoke debugging board. This was created specifically for use for the customer project and their IVI. This was referred to as the ‘Ben Debug Board’ or the ‘Benbug Board’, named after the engineer primarily responsible for development.
Codethink reviewed the initial design of the debugging board and the connections in use in order to understand how the solution worked. Our team then identified improvements that could be made, selecting compatible parts based on data availability and Linux support.
“The initial prototype used a SPI GPIO expander and some small logic to do various debug controls. The second prototype moved to an Atmel ATMega device to provide more IO, a basic command line interface and some programmable reaction to IO changes.
The ATMega was chosen as there was already support for avr-gcc in Debian and it gave us enough code space to do what we wanted.
Having a control system that could be connected to via a serial terminal allowed the customer to use it as their engineers used Windows laptops which did not allow custom driver loading.” - Ben
The board is in use at customer site and Codethink's offices. Further development on a later iteration of the board, with added robustness is ongoing in the background of other work being carried out. The developments allow for reset and boot mode control as well as JTAG access to system logic devices.
The board was initially designed using Eagle. This was used for the first two revisions due to familiarity. Once KiCad v5 was released, using the Eagle import tool, the work was transferred to KiCad. This free and open source software was used for further development and allowed engineers to move to using a four layer board. It also aligns with our objectives to use open source technology wherever possible.
KiCad is a tool which has been trusted in other cases for PCB layout design and schematic capture in work carried out by Codethink engineers.
The overall bill of materials for the Codethink-developed board works out to be cheaper to produce than the original debugging board yet with greater functionality, demonstrating the effectiveness of the creative approach Codethink engineers took to the issue. This approach was enabled by the trust we had earned from the customer.
Other Content
- Speed Up Embedded Software Testing with QEMU
- Open Source Summit Europe (OSSEU) 2024
- Watch: Real-time Scheduling Fault Simulation
- Improving systemd’s integration testing infrastructure (part 2)
- Meet the Team: Laurence Urhegyi
- A new way to develop on Linux - Part II
- Shaping the future of GNOME: GUADEC 2024
- Developing a cryptographically secure bootloader for RISC-V in Rust
- Meet the Team: Philip Martin
- Improving systemd’s integration testing infrastructure (part 1)
- A new way to develop on Linux
- RISC-V Summit Europe 2024
- Safety Frontier: A Retrospective on ELISA
- Codethink sponsors Outreachy
- The Linux kernel is a CNA - so what?
- GNOME OS + systemd-sysupdate
- 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
- QAnvas and QAD: Streamlining UI Testing for Embedded Systems
- 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
- Achieving Long-Term Maintainability with Open Source
- 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
- Full archive