<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>toorun.dev</title><link>https://toorun.dev/</link><description>Recent content on toorun.dev</description><generator>Hugo -- gohugo.io</generator><language>en-us</language><lastBuildDate>Tue, 07 Apr 2026 08:00:00 +0000</lastBuildDate><atom:link href="https://toorun.dev/index.xml" rel="self" type="application/rss+xml"/><item><title>i.MX6 DDR Calibration: Solving Mysterious RAM Instability with Evidence-Based Diagnosis</title><link>https://toorun.dev/posts/imx6-ddr-calibration-ram-instability/</link><pubDate>Tue, 07 Apr 2026 08:00:00 +0000</pubDate><guid>https://toorun.dev/posts/imx6-ddr-calibration-ram-instability/</guid><description>The Problem: Random Crashes Without Pattern Our custom embedded system based on the i.MX6 processor was experiencing mysterious, unpredictable crashes. The system would lock up or reboot at random intervals with no discernible pattern. We couldn&amp;rsquo;t reproduce the issue on demand, making it nearly impossible to debug using traditional methods.
The symptoms suggested hardware instability, but we had no clear indication of what was failing. It could be:
The CPU? The bootloader?</description></item><item><title>My Tech Notebook: A Diary for Memory, Growth, and Sharing</title><link>https://toorun.dev/posts/tech-notebook-diary/</link><pubDate>Sun, 29 Mar 2026 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/tech-notebook-diary/</guid><description>This blog is not a polished magazine. It is my personal tech notebook — a place to capture what I learn, remember why I built things, and keep a clear trail of my experiences.
Who I am I am an electronic engineer with more than 15 years of software development experience across the full stack of embedded and systems work. My background starts at bare metal and microcontrollers, extends through embedded Linux and embedded systems, and also includes desktop application development and practical infrastructure work.</description></item><item><title>RF Testing in Embedded Systems – Practical Implementation</title><link>https://toorun.dev/posts/rf-testing/</link><pubDate>Sun, 29 Mar 2026 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/rf-testing/</guid><description>RF Testing in Embedded Systems Overview RF testing requires devices to support a dedicated test mode that allows controlled configuration of radio parameters.
Typical capabilities include:
Fixed channel selection TX power configuration Bandwidth and modulation selection RX-only mode (disable transmission) Continuous transmission mode These capabilities are required for both wireless interfaces when multiple radios are integrated.
Test Mode Implementation RF test mode is typically implemented based on vendor documentation.
In this case, the implementation follows:</description></item><item><title>WiFi TX Power Configuration and Regulatory Constraints</title><link>https://toorun.dev/posts/wifi-reg-db/</link><pubDate>Sat, 29 Nov 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/wifi-reg-db/</guid><description>WiFi TX Power Configuration Overview WiFi configuration typically allows runtime control of parameters such as channel selection.
However, TX power is not always dynamically configurable and may require configuration during driver initialization.
This is done by providing a TX power configuration binary to the driver.
TX Power Configuration Flow The general workflow:
Generate TX power configuration binary\ Place it in firmware path\ Load driver with configuration\ Verify applied limits Generating TX Power Configuration A configuration file is used to generate a binary representation of TX power limits.</description></item><item><title>NMEA2000 Notes: Address Claim, Heartbeat, and Alarm Publishing</title><link>https://toorun.dev/posts/nmea-2000-notes-address-claim-heartbeat-and-alarm-publishing/</link><pubDate>Thu, 29 May 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/nmea-2000-notes-address-claim-heartbeat-and-alarm-publishing/</guid><description>This is not a full specification reference. It is a practical note to remember how NMEA 2000 works in real systems, what matters during implementation, and what I learned while working with it.
What NMEA 2000 is NMEA 2000 is a communication protocol used in distributed systems over CAN bus.
At the lowest level, it is standard CAN:
250 kbps bus multi-node shared network On top of that, it defines:</description></item><item><title>RED Cybersecurity (EN 18031) – Practical Overview</title><link>https://toorun.dev/posts/red-compliance/</link><pubDate>Sat, 29 Mar 2025 12:30:00 +0000</pubDate><guid>https://toorun.dev/posts/red-compliance/</guid><description>RED Cybersecurity (EN 18031) Overview The RED cybersecurity standard (EN 18031) defines requirements to ensure that radio equipment is secure and does not negatively impact networks, users, or services.
It is structured around three main articles:
3.3.d: Protection of networks and prevention of service degradation 3.3.e: Protection of personal data and privacy 3.3.f: Protection against fraud Applicability Depending on the system design, not all articles may apply.
Typical example:
Systems without user data → privacy requirements may not apply Systems without financial interaction → fraud-related requirements may not apply Network interaction → usually relevant and must be addressed Requirements Structure Each article is divided into:</description></item></channel></rss>