[{"content":"Getting from schematic to a working board is rarely straightforward — component placement, trace routing, impedance, thermal relief and DFM constraints all interact. At Electronics Consult I work through that process iteratively, optimising layouts for performance and cost before sign-off.\nWhat I can help with # Schematic capture and PCB layout (KiCad) Design review and optimisation of existing boards Component selection and BOM cost reduction Small-volume assembly and bring-up for prototypes and pilots Daughter boards, breakout boards and interface adaptors for embedded Linux SBCs Typical use cases # This service suits teams who need a reliable prototype quickly — startups validating hardware before a larger production run, or product teams adding a custom interface board to an existing platform. Small-volume builds avoid the overhead of full production while still producing boards you can put in front of customers or investors.\nDiscuss your project →\n","externalUrl":null,"permalink":"/services/pcb-design-assembly/","section":"Services","summary":"Getting from schematic to a working board is rarely straightforward — component placement, trace routing, impedance, thermal relief and DFM constraints all interact. At Electronics Consult I work through that process iteratively, optimising layouts for performance and cost before sign-off.\n","title":"PCB Design \u0026 Assembly","type":"services"},{"content":"Embedded firmware and software development in Dublin. ARM, ESP32, PIC, Raspberry Pi, embedded Linux and Yocto for IoT and connected devices.\nThere are many powerful microprocessors on the market but what they all have in common is the requirement for quality firmware code development to produce reliable products.\nMicroprocessors \u0026amp; platforms # We have expertise with the following microprocessors and platforms:\nNXP LPC ARM Cortex-M microcontrollers Espressif solutions (ESP8266, ESP32) Microchip PIC microchips Microchip SAM microprocessors Single board computers (SBC) — Raspberry Pi, BeagleBone Silicon Labs solutions (EFR32, MGM32) Languages \u0026amp; frameworks # C / C++ Python HTML / JavaScript Qt Rust Assembly Related writing # ESP32 — Partition calculations ESP32 — Enabling PSRAM EFR32 — RTT Access AI-Assisted Hardware-in-the-Loop for Embedded Linux Matter, Thread \u0026amp; Zigbee: What IoT Developers Need to Know Discuss your project →\n","externalUrl":null,"permalink":"/services/software-development/","section":"Services","summary":"Embedded firmware and software development in Dublin. ARM, ESP32, PIC, Raspberry Pi, embedded Linux and Yocto for IoT and connected devices.\nThere are many powerful microprocessors on the market but what they all have in common is the requirement for quality firmware code development to produce reliable products.\n","title":"Software Development","type":"services"},{"content":"IoT device integration in Dublin: connect devices over Wi-Fi, cellular or LoRaWAN and integrate with cloud services like AWS IoT and ThingSpeak.\nOur expertise # When it comes to IoT, connectivity is usually a vital component. We offer experience in the following connectivity methods:\nWi-Fi — typically implemented via USB dongles or onboard modules (e.g. Raspberry Pi, ESP32). Cellular communications — mobile modules widely available for remote or on-the-move deployments. LoRaWAN — now available as a single-chip solution; ideal for low-power IoT projects requiring wide-area coverage. Which to choose? # Each has its strengths and weaknesses, broken down broadly by range and bandwidth. WiFi suits high-bandwidth local deployments; cellular is ideal where infrastructure reach is needed; LoRaWAN excels at low-power, long-range sensor applications.\nLoRaWAN can be a stand-alone solution or paired with a gateway and a network backbone to facilitate internet connectivity. The Things Network is a community-based gateway service that enables such connectivity.\nWe established a RAK7243 gateway service in February 2020 and can attest to its scope and reliability — approaching a hundred thousand packets received and going strong.\nRelated writing # CSA Testing — Lessons Learned Matter, Thread \u0026amp; Zigbee: What IoT Developers Need to Know Discuss your project →\n","externalUrl":null,"permalink":"/services/device-integration/","section":"Services","summary":"IoT device integration in Dublin: connect devices over Wi-Fi, cellular or LoRaWAN and integrate with cloud services like AWS IoT and ThingSpeak.\nOur expertise # When it comes to IoT, connectivity is usually a vital component. We offer experience in the following connectivity methods:\n","title":"Device Integration","type":"services"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/blog/","section":"Blogs","summary":"","title":"Blogs","type":"blog"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/csa/","section":"Tags","summary":"","title":"Csa","type":"tags"},{"content":"We help startups and product teams design, prototype and ship connected devices. Based in Dublin, we combine embedded Linux, IoT and small-volume PCB expertise to turn your electronics requirements into robust, testable hardware and software.\nWhat we do # Proof-of-concept design \u0026amp; prototyping — translate your idea into a working prototype you can show to customers and investors. Embedded firmware \u0026amp; software development — firmware for ARM, ESP32, ESP8266, PIC, SAM and single-board computers. PCB design \u0026amp; small-volume assembly — optimised layouts and low-volume builds suitable for trials, pilots and early deployments. IoT device integration — connect devices securely over Wi-Fi, cellular or LoRaWAN and integrate with cloud services such as AWS IoT and ThingSpeak. Embedded GUI development — modern, responsive graphical user interfaces for embedded Linux and industrial hardware. Technologies # USB · Bluetooth · Ethernet · GUI · Touch screens · WiFi · ARM · ESP32 · ESP8266 · MGM32 · Power management · AI at the Edge · Machine Learning · CAN · RS485 · SWUpdate · Yocto · IoT · Arduino · Embedded Linux · Cellular communication · Sensors · ZigBee · I²C · SPI · Edge Impulse\nWhy work with us? # Deep embedded expertise — years of experience across microcontrollers, SBCs and embedded Linux. Startup-friendly — used to working with early-stage teams that need quick iteration and clear communication. Small-volume specialists — ideal for proof-of-concepts, pilots and low-volume builds. End-to-end thinking — from PCB and firmware through to cloud integration and user interface. Client feedback # Aoife McHale, Director, LeakWatch Systems\nWe found Owen extremely easy to work with \u0026amp; the quality of his work to be excellent. He delivered results quickly \u0026amp; is a clear and timely communicator. Owen implemented the software on a Linux system to fully test the communications framework and returned extremely high quality documentation at the end of the project. We\u0026rsquo;d have no hesitation working with Owen again and hope to do so again in the future.\nReady to discuss your project? Get in touch →\n","date":"26 April 2026","externalUrl":null,"permalink":"/","section":"Embedded Linux \u0026 IoT Consultancy — Dublin","summary":"We help startups and product teams design, prototype and ship connected devices. Based in Dublin, we combine embedded Linux, IoT and small-volume PCB expertise to turn your electronics requirements into robust, testable hardware and software.\n","title":"Embedded Linux \u0026 IoT Consultancy — Dublin","type":"page"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/esp32/","section":"Tags","summary":"","title":"Esp32","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/iot/","section":"Tags","summary":"","title":"Iot","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/matter/","section":"Tags","summary":"","title":"Matter","type":"tags"},{"content":"If you\u0026rsquo;re building a connected product in 2026, you\u0026rsquo;ve almost certainly been asked: \u0026ldquo;Are you doing Matter or Zigbee?\u0026rdquo; The answer is less straightforward than the marketing suggests. Having recently built a working Matter pressure sensor on ESP32-C6 and gone through CSA certification on the Zigbee side, here are the practical differences that actually affect your development timeline, cost, and product viability.\nFirst, the Terminology # This is where most confusion starts. Matter and Thread are not the same thing, and neither is a direct replacement for Zigbee.\nThread is a low-power IPv6 mesh networking protocol. It defines how data gets from device A to device B wirelessly. Think of it as the road.\nMatter is an application-layer protocol that defines what the data means — \u0026ldquo;turn on the light,\u0026rdquo; \u0026ldquo;report pressure is 0.04 kPa.\u0026rdquo; It rides on top of Thread, Wi-Fi, or Ethernet. Think of it as the language spoken on that road.\nZigbee is both the road and the language in one stack. It has its own mesh networking layer (IEEE 802.15.4, same radio as Thread) and its own application layer (ZCL — Zigbee Cluster Library).\nSo the real comparison is:\nMatter-over-Thread (for battery/low-power devices) Matter-over-Wi-Fi (for mains-powered devices) When someone says \u0026ldquo;we\u0026rsquo;re switching from Zigbee to Matter,\u0026rdquo; they usually mean Matter-over-Thread, since both use 802.15.4 radios and the hardware is often identical — an ESP32-C6 or ESP32-H2 can run either.\nThe State of Matter in 2026 # Matter has come a long way since the 1.0 release in October 2022. We\u0026rsquo;re now at Matter 1.5, with 30+ supported device types and growing. The multi-ecosystem promise is real: one firmware image, and your device works with Apple Home, Google Home, Amazon Alexa, Samsung SmartThings, and Home Assistant. That is genuinely powerful and was never achievable with Zigbee alone.\nBut there are significant rough edges.\nThe Hidden Border Router Requirement # Before getting to OTA, there\u0026rsquo;s a more fundamental friction point: a Matter-over-Thread device is useless without a Thread Border Router in the home.\nIn practice, the Border Router is built into a small set of consumer devices:\nApple TV 4K (3rd gen) and HomePod mini / HomePod 2 Google Nest Hub (2nd gen), Nest Hub Max, Nest Wi-Fi Pro Amazon Echo (4th gen) and select newer Echo devices A standalone option like the Home Assistant Yellow / SkyConnect, or an OpenThread Border Router on a Raspberry Pi If your customer doesn\u0026rsquo;t already own one of these, your \u0026ldquo;Matter-compatible\u0026rdquo; product won\u0026rsquo;t work out of the box. Zigbee doesn\u0026rsquo;t have this problem in the same way — a €20 USB coordinator works with any laptop. This is one of the quieter reasons Matter adoption has been slower than the marketing implied.\nMatter-over-Wi-Fi avoids the Border Router issue entirely, but at the cost of significantly higher power consumption — not viable for battery devices.\nOTA Firmware Updates: Not Ready # This is the one that catches most developers off guard. The Matter specification defines an OTA Provider/Requestor model, but real-world implementation is fragmented:\nAmazon reportedly still doesn\u0026rsquo;t support anything beyond Matter 1.0 device categories for OTA. Apple supports OTA for Wi-Fi devices, but Thread device updates fail through Apple Border Routers in some configurations. Google can download OTA images for Thread devices but often fails to apply them, with IPv6 configuration issues being a common cause. Samsung has announced a \u0026ldquo;controlled rollout\u0026rdquo; for Matter OTA — still being phased in. There is no unified firmware distribution mechanism. Each manufacturer hosts their own update server, and each controller needs to know where to look per device type. If you\u0026rsquo;re used to Zigbee OTA (which, while not perfect, has been working reliably for years through coordinators like ZHA and Zigbee2MQTT), the Matter OTA story will feel immature.\nFor production devices, plan to have an alternative update path. Do not assume Matter OTA will work across all ecosystems your customers use.\nCSA Matter Certification: Expensive and Moving # If you\u0026rsquo;re a small company or consultancy, the certification costs are significant (CSA quotes in USD; figures below converted at ~1 USD = 0.92 EUR):\nCSA Adopter membership: ~€6,500/year (minimum tier for self-certification) Test lab fees: ~€6,500–€9,300 per product Certificate application for your first certified product And the specification moves quickly — 1.0, 1.1, 1.2, 1.3, 1.4, 1.5 in under four years. Each revision can introduce test harness changes and new mandatory clusters. The test harness itself has dependency management issues; version mismatches cause unexpected failures that cost you lab time.\nThe CSA has introduced some mitigations: the Certification Transfer Program (CTP) for white-labelling certified platforms, and FastTrack/Rapid Recertification for products built on a certified platform like Espressif\u0026rsquo;s. These help, but the baseline cost remains high compared to Zigbee certification.\nZigbee: The Pragmatic Choice (With Caveats) # Zigbee has over 4,000 certified devices and a decade of production deployments. The tooling is mature, the certification path is well-understood, and sleepy end devices running on coin cells for years are routine.\nBut Zigbee has its own problems:\nInteroperability is hub-dependent. Cross-brand pairing typically requires a universal coordinator like Home Assistant with ZHA or Zigbee2MQTT. The Zigbee \u0026ldquo;works with everything\u0026rdquo; promise requires that middleman.\nProprietary extensions are rampant. Many manufacturers extend ZCL with custom clusters, breaking cross-vendor compatibility.\nSmart Energy Profile (SEP) is locked down. SEP 1.4a is the latest ratified version with over 250 million deployed devices (mostly utility meters). However, full SEP compliance requires Certicom/Blackberry cryptographic certificates — licensed per-device through Certicom\u0026rsquo;s Device Certificate Authority. This is a separate certification path and adds per-unit cost. It\u0026rsquo;s a significant barrier for smaller players wanting to build energy monitoring products on Zigbee.\nSilicon Vendor Support: Espressif vs Silicon Labs # If you\u0026rsquo;re choosing a platform, the silicon vendor matters as much as the protocol. Espressif and Silicon Labs are the two dominant players in 802.15.4 IoT, and they take very different approaches.\nEspressif # Here\u0026rsquo;s the practical picture from working with both stacks on Espressif silicon:\nMatter (esp-matter / esp-lowcode-matter)\nEspressif\u0026rsquo;s Matter support is solid and improving. The esp-matter SDK supports ESP32, ESP32-C3, ESP32-S3, ESP32-C6, and ESP32-H2 with 30+ device types. Their LowCode framework provides an Arduino-like abstraction that significantly reduces time-to-first-device.\nLimitations: Matter requires substantially more flash and RAM than Zigbee. The LowCode framework is still in beta and currently ESP32-C6 only. Some newer Matter device types (cameras, energy management) are very recent additions and less battle-tested.\nZigbee (esp-zigbee-sdk)\nThe esp-zigbee-sdk supports ESP32-H2 and ESP32-C6 as coordinators, routers, and end devices, with 40+ standard ZCL clusters. It works, but the stack is proprietary (unlike the open-source Matter SDK).\nSilicon Labs # I\u0026rsquo;ve used Silicon Labs\u0026rsquo; Zigbee stack (EmberZNet) for a CSA-certified sleepy end device on the EFR32MG24, so I can speak to the Zigbee side from direct experience. Their Matter/Thread offering I haven\u0026rsquo;t used first-hand, but the architecture is well-documented.\nZigbee (EmberZNet PRO, GSDK)\nThis is the most mature 802.15.4 Zigbee stack on the market — 15+ years of production deployments. EmberZNet v8.x supports the EFR32MG21, MG24, and the newer Series 3 parts (MG26/MG30). Sleepy end device support is solid and well-documented. Critically, Silicon Labs fully supports Smart Energy with CBKE using Certicom ECC certificates (163k1 for SE 1.0, 283k1 for SE 1.2). This is one of their key differentiators — if you need SE for energy/utility products, SiLabs is the path of least resistance.\nA word of caution on SiLabs examples: Having taken a Simplicity Studio Zigbee end device example through to CSA certification, I\u0026rsquo;m fairly confident the out-of-the-box examples would not pass certification as-is. They\u0026rsquo;re useful as a starting point for learning the API, but there is a real gap between \u0026ldquo;example that compiles and runs\u0026rdquo; and \u0026ldquo;firmware that passes the CSA test harness.\u0026rdquo; You should budget significant engineering time for certification hardening on top of the example code.\nThis is where Espressif\u0026rsquo;s LowCode approach has an edge. The LowCode runtime is designed to be certification-ready out of the box — the Matter stack, commissioning, transport, and data model are pre-built and (in principle) pre-certified. Your custom code sits on top as application logic. You\u0026rsquo;re not responsible for making the protocol stack pass certification; Espressif is. With SiLabs, you\u0026rsquo;re building on a certified SDK, but the integration is your problem — and subtle issues in event handling, attribute reporting, or sleep behaviour can and do cause certification failures.\nMatter (SiLabs Matter SDK)\nBuilt on connectedhomeip (same open-source base as Espressif\u0026rsquo;s), currently at v2.8.0 targeting Matter 1.5. Supports Matter-over-Thread on MG24/MG26/MG30 and Matter-over-Wi-Fi on the SiWx917. Less mature than their Zigbee stack but actively developed. SiLabs adds value on top of the open-source base with OTA integration, manufacturing token support, and project generation tooling.\nMultiprotocol — SiLabs\u0026rsquo; trump card\nSilicon Labs supports running Zigbee + Thread + Bluetooth concurrently on a single EFR32 radio using the Co-Processor Communication Daemon (CPCd) with a Linux host. This is production-grade and is exactly what Home Assistant\u0026rsquo;s multiprotocol add-on uses under the hood. Thread RCP (Radio Co-Processor) mode with OpenThread Border Router is well-documented. Espressif has nothing comparable — an ESP32-C6 can do Wi-Fi + Thread but not concurrent Zigbee + Thread.\nSimplicity Studio — the elephant in the room\nSSv5 (Eclipse-based) is painful. Slow startup, enormous install footprint, heavyweight UI, and poor CI/CD integration. Anyone who has used it knows the frustration. The good news: SSv6 went GA in October 2025 and is VS Code-based. The Simplicity Studio VS Code Extension hit v2.0.0 in January 2026 and dropped SSv5 support entirely. If you\u0026rsquo;ve been avoiding SiLabs because of the tooling, SSv6 is worth a fresh look — though it\u0026rsquo;s still early days and not everything has been ported across yet.\nHead-to-Head # Dimension Silicon Labs Espressif Chip cost Higher (~€2.80–€5.50+ for MG24 modules) Lower (~€2.80 ESP32-H2, ~€3.70 ESP32-C6) SDK openness GSDK under proprietary MSLA; radio stacks are closed-source blobs ESP-IDF is Apache 2.0; most components open source Zigbee maturity Industry-leading. 15+ years. Full SE support. Functional but proprietary stack, no SE compliance Matter maturity Solid, built on connectedhomeip + proprietary additions Solid, built on connectedhomeip + LowCode abstraction Multiprotocol Concurrent Zigbee + Thread + BLE on one radio Limited. No concurrent Zigbee + Thread Tooling SSv6 (VS Code) — improving but transitional ESP-IDF + VS Code — lighter, more Unix-friendly Certification support Strong pre-certified modules, deep SE support Good Matter certification, no Zigbee SE Silicon Labs wins on Zigbee maturity, Smart Energy, and multiprotocol. Espressif wins on cost, openness, and developer experience.\nDecision Framework: Which Should You Use? # If you need to ship a reliable product this quarter with predictable certification costs, Zigbee is still the pragmatic choice — especially for battery-powered devices and energy monitoring.\nIf you\u0026rsquo;re building for multi-ecosystem interoperability and your timeline allows for the certification overhead, Matter is the strategic bet.\nFor many products, the answer in 2026 is honestly: both.\nFactor Zigbee Matter Time to market Faster. Mature tooling, stable certification. Slower. Spec still evolving, OTA gaps. Multi-ecosystem Requires universal hub. Native. One firmware, all ecosystems. Power (battery) Excellent. Proven sleepy end devices. Thread: comparable. Wi-Fi: much higher. Certification cost Lower. ~€15K–€18K minimum for first product. OTA updates Reliable through coordinators. Fragmented. Not production-ready across ecosystems. Future investment Stable but not where industry money is going. Heavy backing from Apple, Google, Amazon, Samsung. Smart Energy Supported (with Certicom licensing). Not yet in spec. My Take # I\u0026rsquo;ve published a Matter pressure sensor implementation using Espressif\u0026rsquo;s LowCode framework as a reference: esp-lowcode-matter (pressure sensor fork).\nThe driver callback is a single function:\nvoid app_driver_read_and_report_feature(system_timer_handle_t timer_handle, void *user_data) { float pressure_kpa = 0.0f; int ret = pressure_sensor_wsen_pdus_get_kpa(I2C_PORT, \u0026amp;pressure_kpa); if (ret != 0) { return; } int16_t matter_value = (int16_t)(pressure_kpa * 10.0f); // 0.1 kPa units low_code_feature_data_t update_data = { .details = { .endpoint_id = 1, .feature_id = LOW_CODE_FEATURE_ID_PRESSURE_SENSOR_VALUE }, .value = { .type = LOW_CODE_VALUE_TYPE_INTEGER, .value_len = sizeof(int16_t), .value = (uint8_t *)\u0026amp;matter_value }, }; low_code_feature_update_to_system(\u0026amp;update_data); } That\u0026rsquo;s it. No Matter cluster registration, no commissioning code, no OTA setup, no fabric management — LowCode handles all of that under the hood. Compare that to a few thousand lines of integration glue you\u0026rsquo;d typically write directly against connectedhomeip, and the appeal of the certification-ready runtime model becomes clear.\nGet in touch to learn more about embedded IoT development.\n","date":"26 April 2026","externalUrl":null,"permalink":"/blog/matter-thread-zigbee-what-iot-developers-need-to-know-before-choosing/","section":"Blogs","summary":"If you’re building a connected product in 2026, you’ve almost certainly been asked: “Are you doing Matter or Zigbee?” The answer is less straightforward than the marketing suggests. Having recently built a working Matter pressure sensor on ESP32-C6 and gone through CSA certification on the Zigbee side, here are the practical differences that actually affect your development timeline, cost, and product viability.\n","title":"Matter, Thread \u0026 Zigbee: What IoT Developers Need to Know Before Choosing","type":"blog"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/silicon-labs/","section":"Tags","summary":"","title":"Silicon-Labs","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/","section":"Tags","summary":"","title":"Tags","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/thread/","section":"Tags","summary":"","title":"Thread","type":"tags"},{"content":"","date":"26 April 2026","externalUrl":null,"permalink":"/tags/zigbee/","section":"Tags","summary":"","title":"Zigbee","type":"tags"},{"content":"","date":"1 March 2026","externalUrl":null,"permalink":"/tags/debugging/","section":"Tags","summary":"","title":"Debugging","type":"tags"},{"content":" The One-Line Fix That Took Days # or: why your mental model of the hardware matters more than your register dumps # A step-by-step debug walkthrough for diagnosing a blank display on an embedded board — the checks, tools and pitfalls from a real engineering project.\nTL;DR # The 4\u0026quot; 720×720 RGB display on my Luckfox Pico Ultra W was blank under a custom Yocto image. It worked fine on the stock buildroot firmware from the vendor. Everything I could measure matched: device tree, VOP registers, clocks, IOMUX, CMA totals, DRM state. Days of register-level debugging got nowhere.\nThe actual cause: the panel adapter board carries a tiny WCH CH32V003F4 RISC-V MCU whose reset line is wired to GPIO0_A1 on the RV1106. Stock\u0026rsquo;s U-Boot releases that reset early in boot with gpio set 1 1. My U-Boot didn\u0026rsquo;t. So the panel\u0026rsquo;s on-board MCU sat in reset forever, the panel never ran its init sequence, and no matter how correctly the VOP fed it pixels, nothing showed up.\nThe fix: three lines.\nstatic int luckfox_execute_cmd(void) { run_command(\u0026#34;gpio set 1 1\u0026#34;, 0); return 0; } … plus CONFIG_CMD_GPIO=y (otherwise run_command silently fails with Unknown command 'gpio') and CONFIG_LOGO=y + CONFIG_FRAMEBUFFER_CONSOLE=y in the Linux kernel (otherwise DRM allocates an empty framebuffer and VOP scans zeros onto the now-awake panel, which the human eye is absolutely incapable of distinguishing from \u0026ldquo;still blank\u0026rdquo;).\nNone of that is in the upstream rockchip-linux/u-boot tree I was building from. All of it lives quietly in the Luckfox SDK fork.\nIf you\u0026rsquo;re here because your Luckfox Pico Ultra W\u0026rsquo;s screen is dark, the short version is: add those three things. The rest of this post is the debugging journey that got me there, because I think the journey matters.\nThe Setup # I was building a Yocto BSP for the Luckfox Pico Ultra W because the stock buildroot image is fine for a hello-world demo but not for anything that needs a modern distro, modern systemd, reproducible builds, or packages I actually wanted.\nThe hardware:\nRV1106G3 (Cortex-A7, 1.1 GHz, single-core) 256 MB DDR3L 8 GB eMMC AIC8800DC for WiFi/BT 4\u0026quot; round 720×720 LCD over parallel RGB + GT911 touch over I²C All the peripherals came up under my Yocto image: NPU hit 332 FPS on BlazeFace, the microphone captured stereo PCM, Ethernet and the SDIO WiFi chip enumerated correctly. Backlight PWM toggled. Everything except the actual pixels on the actual LCD.\nThe Symptom # Power on. Backlight lights. Screen stays uniformly dark. Not a flicker, not an eyestrain-level-of-gray. Black. Stock firmware on the exact same board ran the Luckfox logo on the screen from U-Boot onwards, through the kernel handoff, all the way to the buildroot login prompt. So the hardware worked. Something in my build didn\u0026rsquo;t.\nThe (Long) List of Dead Ends # I\u0026rsquo;ll summarise the theories I chased and then marked \u0026ldquo;does not help\u0026rdquo; in my memory notes. I spent somewhere north of three weeks on this.\nDRM_MODE_CONNECTOR_DPI missing from the VOP output-switch. The Rockchip rgb driver sets output_type = DPI, but the VOP\u0026rsquo;s atomic_enable switch only had cases for LVDS, HDMI, DSI. So rgb_en never got set. This was a real bug — in an older commit of the SDK kernel. Current kernel already had a DPI: fallthrough to LVDS:. No-op fix. GRF_SOC_CON1 register comparison. A community thread suggested this register held RGB output-mux bits. I dumped it on the stock board (0x6C4) and on mine (also 0x6C4 after correcting a README typo). Identical. Dead end, but a confusing one because the README initially said 0xC8 and I believed it for days. U-Boot needs to do the display init. Some Rockchip boards do the first display init from U-Boot and hand off to the kernel via the drm-logo reserved-memory region. I spent two evenings wiring that up and verifying the panel/backlight/VOP nodes appeared in the U-Boot DTB. Then I dumped the stock U-Boot\u0026rsquo;s DTB — it has no display nodes at all. Stock U-Boot does not touch the display. Dead end. rockchip,data-sync-bypass on the rgb node. Someone\u0026rsquo;s working config had it. Mine didn\u0026rsquo;t. Added it. Still blank. Checked stock: stock doesn\u0026rsquo;t have it either. Reverted. assigned-clock-rates for dclk_vop. Without it the clock came up at 125 MHz instead of 30 MHz (per clk_summary). Added it. Clock came up right. Still blank. reset-gpios on the panel node with a 200 ms reset-delay. Stock has no reset-gpios. Reverted. route_rgb status = \u0026quot;okay\u0026quot;. Stock has it disabled. Reverted. CMA_INACTIVE. Stock\u0026rsquo;s dtsi has linux,cma { inactive; } which I read as \u0026ldquo;CMA never starts\u0026rdquo;. I was wrong — the keyword is parsed by the Rockchip-specific CONFIG_CMA_INACTIVE kernel option and means \u0026ldquo;don\u0026rsquo;t activate until a consumer asks for it\u0026rdquo;, which is what you want. CMA on mine reported 42 MB. rk_dma_heap_cma=66M on the kernel command line. This one was at least real and useful: the Rockchip DRM driver allocates from a dedicated rk_dma_heap CMA pool separate from linux,cma. Without the cmdline parameter, CmaTotal only showed the small dtsi pool. Adding it gave me 77824 kB total, which matched stock exactly. The panel was still blank. At this point I stopped and re-read my own notes because every individual data point now matched a working system and the panel was still dark. The Phase 2 Dump # Out of ideas, I wrote a small shell script (S99zdump) that captured /proc/cmdline, /proc/meminfo, /sys/class/drm/*, the VOP register window via busybox devmem, and a tarball of /proc/device-tree, and dd\u0026rsquo;d the output to /oem. I injected it into a copy of the stock buildroot rootfs with debugfs, re-flashed, let it boot, rebooted into maskrom, and used upgrade_tool rl to read /oem back. Roughly an hour per round trip.\nThe dump showed a few interesting things:\nCmaTotal = 77824 kB. Matched mine after I added rk_dma_heap_cma. /proc/cmdline was almost identical to mine. VOP register dump was nearly all zero. That last one threw me. On my system the VOP register window was fully populated — all the timing registers, framebuffer addresses, win1 config, the lot. On stock, almost every register was 0.\nI spent another hour convincing myself stock was driving the display a completely different way. Maybe through OP-TEE. Maybe through a secure-world handoff. Maybe U-Boot set up the whole thing and kernel just left it alone.\nNone of that was right either. The real explanation was much simpler and much more embarrassing: the stock image I captured had never been configured to enable RGB output. The stock buildroot ships with the panel, rgb, and linux,cma nodes all set to disabled, and the user (me, any user) has to run luckfox-config to turn on the display. Running it flips those three nodes to okay and uses fdtoverlay to patch the DTB in the boot partition in-place. I flashed stock, checked /mnt/cfg, saw nothing there, concluded \u0026ldquo;stock doesn\u0026rsquo;t use overlays at runtime\u0026rdquo;, and missed that stock as I had flashed it was also blank. The VOP registers were zero on stock because the driver had never bound. I was comparing a blank system to a blank system.\nI had been treating that data as the reference for weeks.\nThe Clue That Broke It # At this point I stopped probing and just looked at the adapter board with real eyes. Three things stood out on the silkscreen:\na pad marked DIO a pin marked GT911 WCHV003F4 The first two I shrugged off. DIO is ambiguous, and GT911 is the touch controller I already knew about.\nThe third one hit like a brick. WCHV003F4 is the silkscreen for a WCH CH32V003F4, a 20-pin TSSOP RISC-V microcontroller. It\u0026rsquo;s $0.10 in bulk. And it has no business being on a passive RGB panel adapter.\nSuddenly my mental model shattered. The adapter isn\u0026rsquo;t a passive dumb RGB panel. It\u0026rsquo;s an active board with an MCU that drives the panel\u0026rsquo;s internal controller. That MCU needs to be awake before the panel will show anything. My custom Yocto build wasn\u0026rsquo;t booting it.\nI went looking for where stock wakes it up.\nFinding the Reset # In the Luckfox SDK tree there\u0026rsquo;s a file called project/cfg/BoardConfig_IPC/BoardConfig-EMMC-Buildroot-RV1106_Luckfox_Pico_Ultra-IPC.mk. One line jumped out:\nexport RK_UBOOT_DEFCONFIG_FRAGMENT=\u0026#34;rk-emmc.config rv1106-luckfox-rgb-reset.config\u0026#34; rv1106-luckfox-rgb-reset.config. That\u0026rsquo;s very specific. Inside:\nCONFIG_LUCKFOX_EXECUTE_CMD=y And in the Luckfox fork of U-Boot, arch/arm/mach-rockchip/board.c:\n#ifdef CONFIG_LUCKFOX_EXECUTE_CMD static int luckfox_execute_cmd(void) { /* Luckfox Pico RGB MCU reset gpio */ run_command(\u0026#34;gpio set 1 1\u0026#34;, 0); return 0; } #endif And further down in the same file, inside board_late_init:\n#ifdef CONFIG_LUCKFOX_EXECUTE_CMD luckfox_execute_cmd(); #endif There it is. gpio set 1 1 in U-Boot command syntax means \u0026ldquo;set GPIO number 1 high\u0026rdquo; — that\u0026rsquo;s GPIO0_A1, the reset line for the adapter\u0026rsquo;s CH32V003. Without it, the MCU stays in reset forever.\nThis symbol and function do not exist in rockchip-linux/u-boot, which is the tree my Yocto recipe fetches from. They only live in the LuckfoxTECH fork. My build had no knowledge of any of this.\nThe Cargo-Cult Moment # I added the Kconfig symbol, the function, and the call site via a do_configure:prepend awk script in my U-Boot recipe, rebuilt, reflashed, and rebooted. The screen was still dark.\nThis was the point where I almost lost it. I had found the exact patch stock uses, ported it correctly, confirmed it landed in the built U-Boot binary, and the display was still blank.\nI broke into U-Boot, typed gpio set 1 1 at the prompt, and got back:\nUnknown command \u0026#39;gpio\u0026#39; - try \u0026#39;help\u0026#39; My U-Boot didn\u0026rsquo;t have CONFIG_CMD_GPIO=y. The gpio command didn\u0026rsquo;t exist. run_command(\u0026quot;gpio set 1 1\u0026quot;, 0) had been silently returning an error and luckfox_execute_cmd had been ignoring that error. For the entire boot, every boot, since I had added the code.\nAdded CONFIG_CMD_GPIO=y to the same config fragment. Rebuilt. Reflashed. Booted. Screen came up.\nExcept it came up showing… black.\nThe Last Piece # I knew at this point that the panel was alive (the adapter MCU was now being released from reset, and a subtle flicker on boot told me something was going through). But the framebuffer was empty. With the MCU awake, I filled /dev/fb0 with 0xffs. Screen stayed dark.\nThat\u0026rsquo;s when I noticed what was in rv1106-emmc.cfg:\n# Note: stock Buildroot does NOT enable VT_CONSOLE or FRAMEBUFFER_CONSOLE. # fbcon allocates its own framebuffer (at a different address than drm-logo) # which interferes with the proper VOP→panel handoff. Display stays blank # despite all other registers being correct. Match stock\u0026#39;s minimal config. I wrote that comment. Weeks ago. When I was still debugging via register comparisons and had convinced myself, wrongly, that fbcon was interfering. The cargo cult ran deep.\nThe truth was the opposite. Stock\u0026rsquo;s real kernel defconfig (luckfox_rv1106_linux_defconfig, which I had never built against because I used the generic rv1106_defconfig instead) enables CONFIG_FRAMEBUFFER_CONSOLE=y and CONFIG_LOGO=y. Without them, the kernel allocates a DRM framebuffer and then never writes anything into it. The VOP faithfully scans that buffer to the panel at 31.25 MHz, 49 Hz, and the panel faithfully renders all-zero pixels. Which is black. Which my eye reads as \u0026ldquo;still broken\u0026rdquo;.\nEnabled the four options — VT, VT_CONSOLE, FRAMEBUFFER_CONSOLE, LOGO, LOGO_LINUX_CLUT224 — rebuilt, reflashed, rebooted.\nThe Tux penguin came up.\nWhat I Learned # Question the dataset, not just the hypothesis. I spent a lot of energy comparing things to a \u0026ldquo;working stock\u0026rdquo; that was never actually working. Every time I would have saved days by re-checking whether my reference was the reference I thought it was. Ask what it looks like, not what your probes say. The silkscreen on the adapter board was visible all along. I could have caught WCHV003F4 in a five-second visual inspection on day one. Instead I was three weeks deep reading VOP register definitions. Silent failures in wrapper layers are the worst failures. U-Boot\u0026rsquo;s run_command silently ignoring \u0026ldquo;Unknown command \u0026lsquo;gpio\u0026rsquo;\u0026rdquo; cost me hours on its own — and it wasn\u0026rsquo;t the only one on this project. (The Rockchip kernel\u0026rsquo;s scripts/gcc-wrapper.py silently deletes .o files whose gcc output contains a non-whitelisted warning, which made an entire separate debugging session on the AIC8800DC WiFi driver look like a mysterious \u0026ldquo;make: Error 1 with no output\u0026rdquo; when it was really a GCC 13 dangling-pointer false positive.) Cargo-cult comments are worse than no comments. The fbcon-disabled comment in my cfg file wasn\u0026rsquo;t just wrong, it was actively blocking me from trying the right thing, because I trusted my own past self. The LuckfoxTECH SDK is a fork of upstream Rockchip. If you build from upstream, you will miss patches that the vendor quietly relies on. Plan for that. Either build from the LuckfoxTECH repo directly, or track which fork-only patches your board needs and port them explicitly. The Current State # A Yocto BSP for the Luckfox Pico Ultra W lives at github.com/OOHehir/luckfox-pico-yocto. It builds a bootable WIC image with a working display, working NPU (332 FPS on BlazeFace via rknn_set_io_mem), working microphone, working AIC8800DC WiFi (driver compiles on SDK kernel 5.10.160 once you suppress the GCC 13 -Wdangling-pointer false positive in rwnx_rx.c), and a small CGI status page with a toggleable heartbeat LED, reachable at http://\u0026lt;board-ip\u0026gt;/ once you get DHCP.\nThe recipe layer is self-contained — it needs only poky, nothing from the RK3506-targeted meta-luckfox-bsp or meta-luckfox-distro layers. Clone, source oe-init-build-env, bitbake luckfox-image-minimal, flash with rkdeveloptool, boot.\nStill open:\ncamera CSI (sc3336 / mis5001) hardware H.264 via mpp_vcodec OP-TEE secure boot watchdog RTC alarms — all still untapped, all in the DT If you\u0026rsquo;re building for the same board and hit the blank-screen wall, skip the register dumps and go straight to the three things above. You\u0026rsquo;ll save yourself a month.\nThe WCH CH32V003F4 located on the screen adapter board\n","date":"1 March 2026","externalUrl":null,"permalink":"/blog/debugging-blank-display/","section":"Blogs","summary":"The One-Line Fix That Took Days # or: why your mental model of the hardware matters more than your register dumps # A step-by-step debug walkthrough for diagnosing a blank display on an embedded board — the checks, tools and pitfalls from a real engineering project.\n","title":"Debugging a Blank Display on an Embedded Board","type":"blog"},{"content":"","date":"1 March 2026","externalUrl":null,"permalink":"/tags/display/","section":"Tags","summary":"","title":"Display","type":"tags"},{"content":"","date":"1 March 2026","externalUrl":null,"permalink":"/tags/embedded-linux/","section":"Tags","summary":"","title":"Embedded-Linux","type":"tags"},{"content":"","date":"1 March 2026","externalUrl":null,"permalink":"/tags/hardware/","section":"Tags","summary":"","title":"Hardware","type":"tags"},{"content":"","date":"15 February 2026","externalUrl":null,"permalink":"/tags/ai/","section":"Tags","summary":"","title":"Ai","type":"tags"},{"content":" AI-Assisted Hardware-in-the-Loop for Embedded Linux # AI coding assistants are genuinely useful for embedded Linux work — navigating unfamiliar build systems, writing device tree overlays, debugging kernel configs. But they hit a wall the moment physical hardware is involved. The agent can modify source files and run builds, but it cannot flash the board, watch it boot, or read back what happened.\nThis post covers a practical approach to closing that gap: giving an AI agent direct access to development hardware through a controlled interface, turning it into a proper hardware-in-the-loop participant.\nThe Project # We are porting the Luckfox Pico Ultra SDK from Buildroot to Yocto (now public). The stock Luckfox SDK is Buildroot with a substantial shell script wrapping the entire build and flash process. Yocto gives us reproducible builds, layer-based customisation, and a package feed — but the porting process involves a lot of iteration. Build a rootfs, flash it, check if it boots, examine what went wrong, adjust, repeat.\nThe AI agent (Claude Code) runs inside a VirtualBox VM. It can read the SDK sources, modify recipes, and kick off builds. But it has no way to flash the result onto the Luckfox board connected via USB to the host machine. USB passthrough to VMs is unreliable for Rockchip devices — the chip re-enumerates during the flash process, which breaks the passthrough session.\nWhat does pass through reliably to the VM is a USB serial adapter and a small USB relay board. The agent uses the serial adapter to read console output directly, and the relay board to power-cycle the target and place it into flash mode — no human hands required. The only piece that cannot live inside the VM is the Rockchip flash tool itself, because of the re-enumeration problem.\nThe Approach # Rather than fighting USB passthrough, we built a small MCP server (gatecmd) that runs on the host and exposes whitelisted commands to the agent over HTTP. The agent connects from inside the VM and can:\nList connected Rockchip devices (upgrade_tool ld) Flash loaders, firmware, and partition images Read device and storage information Manage files in a shared staging directory Every command is validated against an allowlist with pattern-matched arguments. The agent cannot execute arbitrary commands — only pre-defined operations with pre-defined argument structures. File paths are restricted to a single shared directory, so the agent cannot read or write arbitrary host files.\nExample config:\nfile_root: \u0026#34;/home/user/vm-shared\u0026#34; commands: - name: upgrade_tool binary: /opt/upgrade_tool_v2.17/upgrade_tool description: \u0026#34;Rockchip firmware development tool\u0026#34; allowed_args: - pattern: \u0026#34;ld\u0026#34; - pattern: \u0026#34;db {file}\u0026#34; file_args: [\u0026#34;file\u0026#34;] - pattern: \u0026#34;ul {file}\u0026#34; file_args: [\u0026#34;file\u0026#34;] - pattern: \u0026#34;uf {file}\u0026#34; file_args: [\u0026#34;file\u0026#34;] - pattern: \u0026#34;wl {offset} {file}\u0026#34; file_args: [\u0026#34;file\u0026#34;] timeout_secs: 120 The Workflow # The development loop now looks like this:\nThe agent modifies a Yocto recipe or kernel config inside the VM It runs the build It copies the resulting image to the shared folder It triggers the relay to power-cycle the board into flash mode It calls upgrade_tool through the MCP server to flash the board It triggers the relay again to boot normally It reads the serial console to watch the boot process It diagnoses what went wrong and goes back to step 1 The agent handles the entire cycle autonomously — including the physical steps of power-cycling and entering flash mode. It can attempt a flash, see it fail, check device state, read the kernel panic on the console, and adjust its approach. The same iterative process a developer would follow at a bench, but without needing someone sitting there.\nWhat This Actually Gives You # The value is not that the AI does anything a developer could not do manually. It is that the feedback loop runs without human intervention. Porting an SDK to Yocto involves a large number of small iterations — a missing kernel module, a wrong device tree property, a rootfs that mounts but cannot find init. Each cycle is straightforward to diagnose but tedious to execute manually.\nGiving the agent hardware access turns these from \u0026ldquo;wait for a developer to sit down and flash the board\u0026rdquo; into background tasks that progress on their own. The developer reviews results and makes architectural decisions rather than babysitting the flash-boot-debug loop.\nSecurity Considerations # Letting an AI agent run commands on your host machine is exactly as dangerous as it sounds. The security model here is deliberately restrictive:\nAllowlist-only execution — only commands explicitly defined in the YAML config can run Pattern-matched arguments — the agent cannot inject arbitrary flags or subcommands No shell — commands execute directly, never through sh -c Scoped file access — all file paths must resolve under a single configured directory Bearer token auth — the MCP endpoint requires a shared secret This is not a general-purpose remote execution framework. It is a narrow interface designed around one specific workflow: an AI agent building and flashing embedded firmware.\nPractical Notes # Rockchip USB re-enumeration: The Rockchip bootrom, loader, and firmware modes all present as different USB devices. During a flash sequence, the device disappears and reappears on the bus. This is why VM USB passthrough fails — the host reassigns the device. Running the flash tool on the host avoids this entirely.\nShared folder timing: VirtualBox shared folders can have stale caches. The built-in file management tools (list_files, copy_file) operate on the host side directly, so the agent can verify what is actually present before flashing.\nSerial and relay passthrough: Unlike the Rockchip flash interface, simple USB devices like serial adapters and relay boards pass through to a VM without issue — they do not re-enumerate during use. The agent accesses these directly from inside the VM, so no MCP proxy is needed for power control or console access. This keeps the trust boundary clean: only the flash tool runs on the host.\nTimeout management: Flashing a full firmware image can take over a minute. Per-command timeouts in the config prevent hung flash operations from blocking the agent indefinitely.\nSource # The MCP server (gatecmd) is written in Rust and available on GitHub. It includes the Rockchip upgrade_tool v2.17 binary and an English translation of the original Chinese user guide.\n","date":"15 February 2026","externalUrl":null,"permalink":"/blog/ai-assisted-hardware-in-the-loop/","section":"Blogs","summary":"AI-Assisted Hardware-in-the-Loop for Embedded Linux # AI coding assistants are genuinely useful for embedded Linux work — navigating unfamiliar build systems, writing device tree overlays, debugging kernel configs. But they hit a wall the moment physical hardware is involved. The agent can modify source files and run builds, but it cannot flash the board, watch it boot, or read back what happened.\n","title":"AI-Assisted Hardware-in-the-Loop for Embedded Linux","type":"blog"},{"content":"","date":"15 February 2026","externalUrl":null,"permalink":"/tags/hil/","section":"Tags","summary":"","title":"Hil","type":"tags"},{"content":"","date":"15 February 2026","externalUrl":null,"permalink":"/tags/testing/","section":"Tags","summary":"","title":"Testing","type":"tags"},{"content":"","date":"15 February 2026","externalUrl":null,"permalink":"/tags/yocto/","section":"Tags","summary":"","title":"Yocto","type":"tags"},{"content":"","date":"1 February 2026","externalUrl":null,"permalink":"/tags/certification/","section":"Tags","summary":"","title":"Certification","type":"tags"},{"content":" CSA Testing — Lessons Learned # TL;DR — Lessons learned bringing Zigbee end devices through CSA certification testing: what to expect, common failure modes and how to prepare your firmware.\nI recently completed CSA certification for a Zigbee Sleepy End Device and wanted to document a few practical lessons learned. These aren\u0026rsquo;t theoretical concerns — each one had the potential to delay the project significantly if it hadn\u0026rsquo;t gone the right way.\nWho This Is For # This post is aimed at:\nEngineers preparing for CSA Zigbee certification Teams working with Zigbee sleepy end devices Anyone assuming certification is mostly a paperwork exercise If you\u0026rsquo;re early in a Zigbee product lifecycle, this is especially relevant.\nYour SDK Must Already Be CSA Certified # This is an easy detail to miss and one of the biggest schedule risks. Your SDK must already have CSA certification before your product can be certified. That process can take months. In my case, the SDK certification was granted just days before the product entered certification. If it hadn\u0026rsquo;t been approved in time, the entire product certification would have been blocked until that SDK certification completed.\nThis dependency should be checked very early in any certification plan.\nZUTH Is Essential for Zigbee # CSA members get access to ZUTH, the Zigbee Unified Test Harness. In my experience, this tool was essential. In my case, the available sample implementations were not sufficient on their own and required additional work to meet certification requirements. ZUTH allowed issues to be identified and resolved early, well before formal testing. Relying solely on sample code would have introduced significant risk.\nIs Pre-Certification Worth the Cost? # Pre-certification is expensive, so whether it\u0026rsquo;s worthwhile depends on how comfortable you are with the risk of failing certification. In my case:\nThere were some minor known issues There were also uncertainties related to tooling behaviour I wasn\u0026rsquo;t fully confident of a clean first pass Pre-certification effectively validated my own assessment. When the product went through formal certification, it passed without issue. If failure would be costly or disruptive, pre-certification can be worthwhile insurance.\nExpect Firmware Changes for Testing # In some cases, firmware changes are required specifically for certification testing.\nFor Zigbee Sleepy End Devices, this can include shortening the long poll interval to make certain test cases feasible. Any such changes must be:\nClearly documented Controlled so they don\u0026rsquo;t ship unintentionally Justified during testing if questioned Planning for this avoids last-minute changes under pressure.\nSummary # CSA certification isn\u0026rsquo;t technically difficult, but it is process-sensitive. Small oversights can easily result in multi-month delays.\nKey takeaways:\nConfirm SDK certification status early Use ZUTH rather than relying solely on sample implementations Consider pre-certification if certainty matters Expect test-specific firmware modifications Hopefully this helps reduce some of the uncertainty for anyone heading into Zigbee certification for the first time.\n","date":"1 February 2026","externalUrl":null,"permalink":"/blog/csa-testing-lessons-learned/","section":"Blogs","summary":"CSA Testing — Lessons Learned # TL;DR — Lessons learned bringing Zigbee end devices through CSA certification testing: what to expect, common failure modes and how to prepare your firmware.\n","title":"CSA Testing — Lessons Learned","type":"blog"},{"content":"","date":"1 January 2026","externalUrl":null,"permalink":"/tags/efr32/","section":"Tags","summary":"","title":"Efr32","type":"tags"},{"content":" EFR32 — Accessing Serial Output via RTT from the Command Line # Setting up Segger RTT for fast debug output on Silicon Labs EFR32 microcontrollers — practical configuration notes from an embedded engineering consultancy.\nWho Is This For? # This post is for embedded developers working with EFR32 devices and a J-Link–based debugger (e.g. WSTK) who already have SEGGER RTT compiled into their firmware and want practical ways to connect, view logs, and script RTT access using Simplicity Commander and Python (pylink).\nIntroduction # The EFR32 series from Silicon Labs supports SEGGER Real-Time Transfer (RTT) for debug output. Unlike UART, RTT requires no dedicated pins and has virtually zero timing impact on your firmware. It works whenever a J-Link debugger is connected — which includes the built-in debugger on WSTK development kits.\nThe method to capture this output from the command line is using Simplicity Commander, Silicon Labs\u0026rsquo; CLI tool for device programming and debugging.\nBasic Connection # To stream RTT output to your terminal:\ncommander rtt connect --device EFR32MG22C224F512GN32 You should see something like:\nConnecting to J-Link... Found RTT block at 0x20000000 Connected to RTT channel 0 Hello from EFR32! Sensor reading: 23.5 Press Ctrl+C to disconnect.\nIf you have multiple J-Links connected, specify which one using --serialno:\ncommander rtt connect --device EFR32MG22C224F512GN32 --serialno 440123456 Find your serial number with:\ncommander adapter probe Automated Capture for Testing # For automated test harnesses or CI pipelines, two options are particularly useful:\nTimeout — exit after N seconds of no data received End marker — exit when a specific string appears in the output Using option 1 allows a script to capture output for a fixed duration:\ncommander rtt connect --device EFR32MG22C224F512GN32 --timeout 30 Option 2 allows the capture to stop precisely when tests complete. If your firmware prints a marker like === TEST END === after running tests:\ncommander rtt connect --device EFR32MG22C224F512GN32 --endmarker \u0026#34;=== TEST END ===\u0026#34; A typical test automation script combines flashing, reset, and capture:\n#!/bin/bash DEVICE=EFR32MG22C224F512GN32 # Flash and reset commander flash test_firmware.bin --device $DEVICE commander device reset --device $DEVICE # Capture until tests complete commander rtt connect --device $DEVICE --endmarker \u0026#34;=== TEST END ===\u0026#34; | tee results.log # Check for failures grep -q \u0026#34;0 Failures\u0026#34; results.log \u0026amp;\u0026amp; exit 0 || exit 1 Troubleshooting # After enabling RTT in your firmware you may find the connection fails with:\nRTT block not found in device memory This is normally due to the RTT control block being optimised out by the linker because nothing references it at startup. The solution is to ensure:\nSEGGER RTT sources added to the project (SEGGER_RTT.c, config headers, etc.) At least one up-buffer configured and used (e.g. SEGGER_RTT_WriteString or SEGGER_RTT_printf) Call SEGGER_RTT_Init() early in main(), or mark the RTT block as used in your linker script: __attribute__((used)) SEGGER_RTT_CB _SEGGER_RTT; Another common issue is no output appearing despite a successful connection. Check that:\nYour firmware is actually calling SEGGER_RTT_Write() or SEGGER_RTT_printf() You\u0026rsquo;re reading the correct channel (default is 0, use --terminal N for others) The device hasn\u0026rsquo;t crashed before reaching your print statements To verify the J-Link and device connection are working:\ncommander device info --device EFR32MG22C224F512GN32 Other Useful Options # A few additional flags worth knowing:\n--noreset — attach without resetting the device (useful for catching output from already-running code) --ip 192.168.1.100 — connect to a J-Link over the network --blockaddress 0x20000000 — manually specify RTT block location if auto-detection fails Once working, RTT provides a clean, scriptable way to capture device output without any IDE dependency — perfect for automated testing or production line diagnostics.\nBidirectional RTT with Python # Simplicity Commander can send and receive RTT data via commander rtt connect, but its interaction model is terminal-like and less scriptable than using the pylink Python API directly.\nInstall it with:\npip install pylink-square Reading and Writing # Here\u0026rsquo;s a complete example that connects to an EFR32, reads RTT output, and sends commands:\nimport pylink import time import threading def rtt_reader(jlink, stop_event): \u0026#34;\u0026#34;\u0026#34;Background thread to continuously read RTT output.\u0026#34;\u0026#34;\u0026#34; while not stop_event.is_set(): data = jlink.rtt_read(0, 1024) # list of ints if data: chunk = bytes(data).decode(\u0026#34;utf-8\u0026#34;, errors=\u0026#34;replace\u0026#34;) print(chunk, end=\u0026#34;\u0026#34;, flush=True) def main(): jlink = pylink.JLink() # Connect to J-Link jlink.open() jlink.set_tif(pylink.enums.JLinkInterfaces.SWD) jlink.connect(\u0026#39;EFR32MG22C224F512GN32\u0026#39;) # Start RTT jlink.rtt_start() # Wait for RTT control block to be found while True: try: num_up = jlink.rtt_get_num_up_buffers() num_down = jlink.rtt_get_num_down_buffers() print(f\u0026#34;RTT started: {num_up} up buffer(s), {num_down} down buffer(s)\u0026#34;) break except pylink.errors.JLinkRTTException: time.sleep(0.1) # Start reader thread stop_event = threading.Event() reader = threading.Thread(target=rtt_reader, args=(jlink, stop_event)) reader.start() # Interactive loop - send user input to device try: while True: cmd = input() if cmd: jlink.rtt_write(0, list(cmd.encode() + b\u0026#39;\\n\u0026#39;)) except KeyboardInterrupt: pass finally: stop_event.set() reader.join() jlink.rtt_stop() jlink.close() if __name__ == \u0026#39;__main__\u0026#39;: main() Key Functions # rtt_start() — begin RTT session (call after connect()) rtt_read(channel, num_bytes) — read up to N bytes from an up-buffer rtt_write(channel, data) — write bytes to a down-buffer rtt_get_num_up_buffers() — number of device→host channels rtt_get_num_down_buffers() — number of host→device channels rtt_stop() — end RTT session Firmware Side # To receive data on the device, your firmware needs to read from the RTT down-buffer:\nchar cmd_buffer[64]; unsigned num_bytes = SEGGER_RTT_Read(0, cmd_buffer, sizeof(cmd_buffer)); if (num_bytes \u0026gt; 0) { // Process received command handle_command(cmd_buffer, num_bytes); } ","date":"1 January 2026","externalUrl":null,"permalink":"/blog/efr32-rtt-access/","section":"Blogs","summary":"EFR32 — Accessing Serial Output via RTT from the Command Line # Setting up Segger RTT for fast debug output on Silicon Labs EFR32 microcontrollers — practical configuration notes from an embedded engineering consultancy.\n","title":"EFR32 — Accessing Serial Output via RTT from the Command Line","type":"blog"},{"content":"","date":"1 January 2026","externalUrl":null,"permalink":"/tags/rtt/","section":"Tags","summary":"","title":"Rtt","type":"tags"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/aws/","section":"Tags","summary":"","title":"Aws","type":"tags"},{"content":" ESP32 — Enabling PSRAM # How to enable and use PSRAM on the ESP32, with the configuration steps and gotchas you\u0026rsquo;ll hit in real firmware projects. Notes from an embedded consultancy.\nThe ESP32 has a few hundred kilobytes of internal RAM, residing on the same die as the rest of the chip components. It can be insufficient for some purposes, so ESP32 has the ability to use up to 4 MB of virtual addresses for external PSRAM (Pseudostatic RAM) memory. The external memory is incorporated in the memory map and, with certain restrictions, is usable in the same way as internal data RAM.\nThe method to enable this feature is using \u0026lsquo;Menuconfig\u0026rsquo; \u0026amp; selecting the following options:\n(Top) → Component config → ESP32-specific → Support for external, SPI-connected RAM There are a number of methods of utilising this external RAM as outlined in the Espressif documentation, but perhaps the most useful method is either:\nAdd External RAM to the Capability Allocator Provide External RAM via malloc() Using option 1 allows a running application to allocate memory using a special call, heap_caps_malloc(size, MALLOC_CAP_SPIRAM), \u0026amp; release using the free() call. This method could be useful for allocating large arrays, for example when using TensorFlow.\nOption 2 allows an application to use the more usual malloc() call \u0026amp; release using the same free() call. The build can be configured to try \u0026amp; allocate memory requests over a certain size to external RAM.\nAfter enabling these the user may find themselves facing new, surprising, build errors such as:\nsection `.iram0.text\u0026#39; will not fit in region `iram0_0_seg\u0026#39; IRAM0 segment data does not fit. region `iram0_0_seg\u0026#39; overflowed by 8876 bytes Code which fitted previously now doesn\u0026rsquo;t seem to! It turns out this is normally due to workarounds introduced by Espressif to mitigate against certain silicon bugs in Rev 1 \u0026amp; 2 of the ESP32 chip. These workarounds disable certain ROM code \u0026amp; hence introduce the requirement for more RAM code.\nTo solve this issue check your chip revision using the tool provided by Espressif (part of the idf suite):\nesptool flash_id Hopefully you see something like:\nDetecting chip type... ESP32 Chip is ESP32D0WDQ5 (revision 3) In which case you can set the minimum chip revision in Menuconfig as follows:\n(Top) → Component config → ESP32-specific → Minimum Supported ESP32 Revision → Rev 3 Once enabled the build errors should be resolved \u0026amp; the PSRAM now available.\nIf you need help with production-grade ESP32 firmware or partitioning, take a look at our Software Development services.\n","date":"1 January 2024","externalUrl":null,"permalink":"/blog/esp32-enabling-psram/","section":"Blogs","summary":"ESP32 — Enabling PSRAM # How to enable and use PSRAM on the ESP32, with the configuration steps and gotchas you’ll hit in real firmware projects. Notes from an embedded consultancy.\n","title":"ESP32 — Enabling PSRAM","type":"blog"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/firmware/","section":"Tags","summary":"","title":"Firmware","type":"tags"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/gui/","section":"Tags","summary":"","title":"Gui","type":"tags"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/memory/","section":"Tags","summary":"","title":"Memory","type":"tags"},{"content":"Meritech manufactures automated handwashing stations used in food processing, healthcare and industrial environments. The CleanTech Evo is their flagship unit — a fully automated station that washes and sanitises hands in 12 seconds without any manual contact.\nThe work # Full embedded Linux stack delivered from BSP to application layer:\nYocto BSP — custom Yocto build tailored to the target hardware, including layer configuration, recipe development and image generation EEPROM programming — factory provisioning of device identity and configuration data for soap dispenser modules OTA firmware updates — robust over-the-air update pipeline using SWUpdate and U-Boot, with rollback support to ensure devices in the field can always recover from a failed update AWS integration — device connectivity and telemetry reporting to AWS IoT, enabling remote monitoring and fleet management GUI — embedded graphical user interface for the station\u0026rsquo;s touchscreen, guiding users through the wash cycle and displaying status Hardware control — stepper motor control for the mechanical components of the wash and sanitise cycle Discuss your project →\n","date":"1 January 2024","externalUrl":null,"permalink":"/portfolio/meritech-cleantech/","section":"Portfolio","summary":"Meritech manufactures automated handwashing stations used in food processing, healthcare and industrial environments. The CleanTech Evo is their flagship unit — a fully automated station that washes and sanitises hands in 12 seconds without any manual contact.\n","title":"Meritech CleanTech Evo — Automated Handwashing Station","type":"portfolio"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/ota/","section":"Tags","summary":"","title":"Ota","type":"tags"},{"content":"Selected embedded Linux, IoT and firmware projects delivered by Electronics Consult — from ESP32 LoRaWAN devices to Yocto-based prototype boards.\nFull embedded Linux stack for Meritech\u0026rsquo;s CleanTech Evo automated handwashing stations — Yocto BSP, OTA updates (SWUpdate + U-Boot), AWS IoT integration, GUI and stepper motor control. Embedded firmware design for a Dublin-based IoT startup, LeakWatch Systems. The work included C++ code development on embedded devices (ESP8266) to communicate securely to remote servers. Also included was Python software development on a Linux-based system to facilitate testing of the communications between the devices and server. Creation of software (JavaScript, HTML) to allow the integration of LoRaWAN devices on The Things Network into \u0026lsquo;Homey\u0026rsquo;, a home automation ecosystem. PCB design \u0026amp; assembly of a daughter board add-on featuring an ADV7184 for an Analog Devices Blackfin single board computer running embedded Linux. Development \u0026amp; creation of loadable kernel module (LKM) drivers for Linux single board computers. Custom Yocto builds to support customer requirements. Development of Linux Devicetrees to enable hardware on custom builds. Development of embedded graphical user interfaces (Qt \u0026amp; Microchip solutions) on Linux single board computers to meet customer requirements. Development on a Microchip SAMA5D4 Xplained board for an embedded GUI industrial project. Consultation work for a local artist to develop solutions, source components \u0026amp; assemble prototypes to satisfy the illumination requirements of their work. Discuss your project →\n","date":"1 January 2024","externalUrl":null,"permalink":"/portfolio/","section":"Portfolio","summary":"Selected embedded Linux, IoT and firmware projects delivered by Electronics Consult — from ESP32 LoRaWAN devices to Yocto-based prototype boards.\nFull embedded Linux stack for Meritech’s CleanTech Evo automated handwashing stations — Yocto BSP, OTA updates (SWUpdate + U-Boot), AWS IoT integration, GUI and stepper motor control. Embedded firmware design for a Dublin-based IoT startup, LeakWatch Systems. The work included C++ code development on embedded devices (ESP8266) to communicate securely to remote servers. Also included was Python software development on a Linux-based system to facilitate testing of the communications between the devices and server. Creation of software (JavaScript, HTML) to allow the integration of LoRaWAN devices on The Things Network into ‘Homey’, a home automation ecosystem. PCB design \u0026 assembly of a daughter board add-on featuring an ADV7184 for an Analog Devices Blackfin single board computer running embedded Linux. Development \u0026 creation of loadable kernel module (LKM) drivers for Linux single board computers. Custom Yocto builds to support customer requirements. Development of Linux Devicetrees to enable hardware on custom builds. Development of embedded graphical user interfaces (Qt \u0026 Microchip solutions) on Linux single board computers to meet customer requirements. Development on a Microchip SAMA5D4 Xplained board for an embedded GUI industrial project. Consultation work for a local artist to develop solutions, source components \u0026 assemble prototypes to satisfy the illumination requirements of their work. Discuss your project →\n","title":"Portfolio","type":"portfolio"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/psram/","section":"Tags","summary":"","title":"Psram","type":"tags"},{"content":"","date":"1 January 2024","externalUrl":null,"permalink":"/tags/swupdate/","section":"Tags","summary":"","title":"Swupdate","type":"tags"},{"content":" ESP32 Partition Size Calculations # How to calculate and configure ESP32 flash partitions for OTA updates, NVS and SPIFFS. A practical walkthrough from an embedded engineering consultancy.\nESP32 modules come in various flash memory sizes, the most common being 4MB, but 8MB \u0026amp; 16MB modules are available. The flash memory needs to be partitioned depending on requirements \u0026amp; constraints.\nThe requirements include:\nIs over the air (OTA) updating feature required? Is the main application (app) substantial in size? Is a basic file system (e.g. SPIFFS) required? Constraints include:\nOffset must be a multiple of 4 KB / 0x1000 Type app partitions have to be placed at offsets aligned to 0x10000 (64 K) The bootloader \u0026amp; partition table occupy the region 0x0 to 0x9000 Some \u0026lsquo;standard\u0026rsquo; partition schemes for the 4MB module are:\n\u0026ldquo;Single factory app, no OTA\u0026rdquo;\n# ESP-IDF Partition Table # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x6000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 1M, \u0026ldquo;Factory app, two OTA definitions\u0026rdquo; configuration\n# ESP-IDF Partition Table # Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x4000, otadata, data, ota, 0xd000, 0x2000, phy_init, data, phy, 0xf000, 0x1000, factory, app, factory, 0x10000, 1M, ota_0, app, ota_0, 0x110000, 1M, ota_1, app, ota_1, 0x210000, 1M, Tables can be further complicated with multiple OTA partitions.\nCreating your own table to support a different layout or different sized module can require some tedious calculations. To save time, use the following tool — just input the module size \u0026amp; required SPIFFS size and the table will be generated for you:\nDownload ESP32 Partition Generator\nIf you need help with production-grade ESP32 firmware or partitioning, take a look at our Software Development services.\n","date":"1 January 2023","externalUrl":null,"permalink":"/blog/esp32-partition-calculations/","section":"Blogs","summary":"ESP32 Partition Size Calculations # How to calculate and configure ESP32 flash partitions for OTA updates, NVS and SPIFFS. A practical walkthrough from an embedded engineering consultancy.\n","title":"ESP32 Partition Calculations","type":"blog"},{"content":"","date":"1 January 2023","externalUrl":null,"permalink":"/tags/partitions/","section":"Tags","summary":"","title":"Partitions","type":"tags"},{"content":"Electronics Consult was founded in 2012 by Owen O\u0026rsquo;Hehir and is based in Dublin, Ireland.\nExpertise # The focus is embedded Linux, IoT, Matter/Zigbee/Thread, small-volume PCB design, and firmware development across ARM, Espressif and Silicon Labs platforms. Over more than a decade of consultancy work, projects have been delivered for IoT startups, product teams and individual clients across Ireland and Europe.\nServices # Embedded firmware and software development — from bare-metal microcontrollers to full Yocto-based embedded Linux systems. PCB design and small-volume assembly — prototype boards and low-volume builds for trials and early deployments. IoT device integration — connecting hardware to cloud services over Wi-Fi, cellular and LoRaWAN. Values # Customer service Engineering excellence Flexibility Openness Find me online # Active on GitHub and LinkedIn — feel free to connect or review recent open-source work there.\nDiscuss your project →\n","externalUrl":null,"permalink":"/about/","section":"About","summary":"Electronics Consult was founded in 2012 by Owen O’Hehir and is based in Dublin, Ireland.\nExpertise # The focus is embedded Linux, IoT, Matter/Zigbee/Thread, small-volume PCB design, and firmware development across ARM, Espressif and Silicon Labs platforms. Over more than a decade of consultancy work, projects have been delivered for IoT startups, product teams and individual clients across Ireland and Europe.\n","title":"About","type":"about"},{"content":"Dublin-based, available for remote work worldwide and on-site across Europe.\nFor consulting enquiries, collaboration or technical questions:\nEmail: contact@electronicsconsult.com\nOr use the form below:\nName\nEmail\nMessage\nSend message\n","externalUrl":null,"permalink":"/contact/","section":"Contact","summary":"Dublin-based, available for remote work worldwide and on-site across Europe.\nFor consulting enquiries, collaboration or technical questions:\nEmail: contact@electronicsconsult.com\nOr use the form below:\nName\nEmail\nMessage\nSend message\n","title":"Contact","type":"contact"},{"content":"Embedded GUI development for industrial HMIs, touchscreens and Raspberry Pi. Qt and modern responsive interfaces for embedded Linux hardware.\nMany embedded projects require a user interface and a common solution is the use of touchscreens. Rendering clean, clear \u0026amp; responsive displays requires careful selection of an appropriate framework. Qt has previously been considered the go-to solution for embedded graphical user interface (GUI). With its extensive development environment coupled with a multitude of libraries it enables rapid progression to market. This, however, comes with a cost, which can be prohibitively expensive.\nA number of alternatives are available, and the best fit depends on your use case. For example:\nMicrochip Graphics Suite — naturally focused on Microchip\u0026rsquo;s products (e.g. the SAM range). LVGL — suitable for devices such as the ESP32. Slint — a relatively recent development ported to a number of platforms. Slint is also available in Rust. Our expertise # Here at Electronics Consult we have significant experience developing with both Qt and Microchip Graphics Suite, and have started trials with Slint. We can suggest an appropriate solution for your requirements and help you make your project a reality.\nQt6 Demo # A Qt 6 QML demo running on a Raspberry Pi 4.\nMicrochip Graphics Suite Demo — Meritech CleanTech Evo # Benchtop test of the Meritech CleanTech Evo embedded Linux stack: SAMA5D4 board driving a touchscreen UI, video animation and stepper motor control.\nSlint Rust Demo # A Slint Rust demo running on a Luckfox Pico Ultra BW with a 720 x 720 touchscreen.\nDiscuss your project →\n","externalUrl":null,"permalink":"/portfolio/graphical-user-interface-gui/","section":"Portfolio","summary":"Embedded GUI development for industrial HMIs, touchscreens and Raspberry Pi. Qt and modern responsive interfaces for embedded Linux hardware.\nMany embedded projects require a user interface and a common solution is the use of touchscreens. Rendering clean, clear \u0026 responsive displays requires careful selection of an appropriate framework. Qt has previously been considered the go-to solution for embedded graphical user interface (GUI). With its extensive development environment coupled with a multitude of libraries it enables rapid progression to market. This, however, comes with a cost, which can be prohibitively expensive.\n","title":"Graphical User Interface (GUI) Development","type":"portfolio"},{"content":"","externalUrl":null,"permalink":"/tags/lvgl/","section":"Tags","summary":"","title":"Lvgl","type":"tags"},{"content":"Thanks for getting in touch — I\u0026rsquo;ll get back to you within one business day.\n","externalUrl":null,"permalink":"/contact/thanks/","section":"Contact","summary":"Thanks for getting in touch — I’ll get back to you within one business day.\n","title":"Message sent","type":"contact"},{"content":"","externalUrl":null,"permalink":"/tags/qt/","section":"Tags","summary":"","title":"Qt","type":"tags"},{"content":"Embedded Linux, IoT, firmware and small-volume PCB services from a Dublin consultancy. Helping startups go from prototype to working hardware.\nAt Electronics Consult we offer the following services, customised to your requirements:\nPCB Design \u0026amp; Assembly — optimised layouts and low-volume builds for prototypes, pilots and early-stage deployments. Software Development — embedded firmware and software for ARM, ESP32, PIC, Raspberry Pi, embedded Linux and Yocto. Device Integration — connect devices over Wi-Fi, cellular or LoRaWAN and integrate with cloud services such as AWS IoT and ThingSpeak. Discuss your project →\n","externalUrl":null,"permalink":"/services/","section":"Services","summary":"Embedded Linux, IoT, firmware and small-volume PCB services from a Dublin consultancy. Helping startups go from prototype to working hardware.\nAt Electronics Consult we offer the following services, customised to your requirements:\n","title":"Services","type":"services"},{"content":"","externalUrl":null,"permalink":"/tags/slint/","section":"Tags","summary":"","title":"Slint","type":"tags"},{"content":"Here at Electronics Consult we pride ourselves on quality work and believe the voices of our customers speak for themselves.\nVinnie Kilduff, Creator/Founder @ Parakeet — Grammy Award Winning Musician/Writer/Songwriter/Producer\nOwen has built me a Custom Music Sampler from scratch which includes all the original specifications I asked him for. This type of sampler was not available on the market and we have had a very successful outcome and I must say I am very pleased with the result.\nAs a hardware engineer Owen pays attention to detail and he definitely solved a major technical challenge for me. I found him easy to work with as he took a very professional approach to each and every challenge.\nAoife McHale, Director, LeakWatch Systems — Dublin-based IoT company\nOwen from Electronics Consult worked with us to help strategise, design and implement the firmware on our embedded IoT products. He executed secure communications between ESP8266 embedded devices \u0026amp; remote servers.\nWe found Owen extremely easy to work with \u0026amp; the quality of his work to be excellent. He delivered results quickly \u0026amp; is a clear and timely communicator. Owen implemented the software on a Linux system to fully test the communications framework and returned extremely high quality documentation at the end of the project. We\u0026rsquo;d have no hesitation working with Owen again and hope to do so again in the future.\nJoanne Parle, Kildare-based Artist\nOwen helped me to implement a lighting solution for my artistic designs. He examined different possible solutions, sourced components \u0026amp; carried out the necessary assembly, all to an excellent standard. I found Owen to be an enthusiastic collaborator \u0026amp; his work of a very high standard. I would highly recommend him to anyone seeking such expertise.\n","externalUrl":null,"permalink":"/testimonials/","section":"Testimonials","summary":"Here at Electronics Consult we pride ourselves on quality work and believe the voices of our customers speak for themselves.\nVinnie Kilduff, Creator/Founder @ Parakeet — Grammy Award Winning Musician/Writer/Songwriter/Producer\n","title":"Testimonials","type":"testimonials"}]