SEGGER's Ozone now supports simulators and third-party probes

SEGGER’s powerful debugger and performance analyzer Ozone, long trusted by J-Link and J-Trace users, is now accessible for simulators and third-party debug probes via the GDB Remote Protocol. “After listening to requests from valued customers and developers, we decided to open up Ozone for use with their debug probes. I encourage every developer to try Ozone — it’s intuitive and powerful, and it shows you exactly what’s happening in your application. One of my favorite features is the source window, which can interleave C/C++/Rust code with disassembly, enabling users to gain maximum insight.” 💬 Rolf Segger, Founder of SEGGER ➡️ For more information, please visit https://lnkd.in/edzmxraZ #Debugger #EmbeddedSystems #JLink

Using #Segger's powerful debugger #Ozone, together with a J-Trace Pro Cortex-M probe, was a game changer that saved me a lot of time while investigating complex #STM32 scenarios in both #baremetal and #RTOS contexts — with the latter especially benefiting from the clear, dynamic, and customizable timeline view. This update, by opening its doors to a wider audience, will bring significant added value. It simply works. ⬇️

Go’s Trace Flight Recorder Go 1.25 introduces the Trace Flight Recorder, a powerful tool for diagnosing production issues and performance bottlenecks with minimal overhead. * Key Benefits: Production-Ready: Continuous tracing with low impact Actionable Insights: Capture only the most recent activity Performance Focused: Identify slow requests, CPU spikes, and GC pauses quickly. * In This Blog: We demonstrate a simple Go web server that records a trace when requests exceed a latency threshold — helping teams analyze issues with precision. 🔗 Read more: https://lnkd.in/e4eZFffU #GoLang #GoProgramming #SoftwareEngineering #PerformanceEngineering #Debugging #DeveloperTools #ProductionDebugging #Observability #BackendDevelopment #MissionXTech #Innovation #TechBlog

The Day a static Variable Broke My Driver Sync Logic I recently spent hours debugging a strange bug while building a multi-instance hardware driver on Zephyr RTOS. I had two different drivers that needed to synchronize their initialization using a shared flag. One driver would signal when reset was done, and the other would wait for it. Seemed simple… until it wasn’t 😅 ⚡ The Bug I wrote a helper like this inside a header file: // sync_helper.h static inline void wait_for_ready(void) { static bool ready = false; if (!ready) { printf("Waiting...\n"); while (!ready) { /* wait */ } } } Then I included it in two .c files: // master.c #include "sync_helper.h" void master_start(void) { // do reset... ready = true; // supposed to wake up others } // slave.c #include "sync_helper.h" void slave_start(void) { wait_for_ready(); // waits forever... } 🔴 Result: The slave got stuck forever. Even though the master set ready = true, the slave never saw it. Why? Because static inside a header creates a separate copy for each .c file. So master.c and slave.c each had their own private ready flag in different memory locations. It wasn’t a race condition — it was symbol scope. 😅 🛠 The Fix I changed it to a proper global: // sync_helper.h #pragma once extern bool ready; static inline void wait_for_ready(void) { while (!ready) { /* wait */ } } // sync_helper.c #include "sync_helper.h" bool ready = false; Now all .c files see the same ready variable, and the synchronization works perfectly. 💡 Lessons Learned static inside a header = one copy per .c file (not shared) extern in header + one definition in .c = single shared global This kind of bug looks like a race condition but is really a linkage issue ⚙️ Embedded Takeaway In embedded development, how your code links is just as important as how it runs. A few misplaced static keywords can silently break cross-driver logic and cost you hours of head-scratching. 💬 Have you ever fought an “invisible global” like this? Drop your war stories below Let’s save each other some debugging pain! #EmbeddedSystems #ZephyrRTOS #CProgramming #Firmware #Debugging #RealTime #RTOS #Linker #StaticVsExtern

september of The Zephyr Project 2025-09-06 : source level / live update debugging don't caught in the mental trap that not having vendor ide means difficult/cumbersome debugging. it's simply not true. example : with SEGGER Microcontroller ozone & j-link, you get source level / visual debugging on virtually any arm or risc-v device. here we see how to trigger a reload automatically after a build on the super monkey and plot some data. zero additional instrumentation in the code. see Chris Gammell's Golioth blog on setup https://lnkd.in/emMi2cqH remember, zephyr is a composition. you get to choose the best tools for you. the artifact of the build is an .elf file. you can use anything that understands .elf files to debug (ozone, openocd, pyocd, misc. vscode plugins, etc)

While profiling some CUDA code on a SLURM cluster I realized I was not working in a very reproducible way (running interactively with uncommitted code, etc.), which could become a problem down the road if I ever needed to know how a certain result was generated, so Calkit now has SLURM integration. And now my Nsight Systems and Compute reports are version controlled and traceable to the code that generated them 🙂 Data-driven decision making can fail if you don't know how the data was generated! 📃 https://lnkd.in/g8xUdgAn #hpc #nvidia #cuda

🔧 Bit Tricks Every Embedded Engineer Should Know Working close to hardware means working with bits. Here are 3 tiny, constant-time C patterns you’ll use everywhere: ⚡ Set / Clear a Bit → Use OR (|) with a mask to set, AND (& ~) to clear. 🔄 Toggle a Bit → XOR (^) flips only the target bit (perfect for flags). 👀 Check a Bit → AND (&) isolates the bit; nonzero = set. These patterns are the backbone of register manipulation, driver code, and even interview questions. Clean, fast, and reliable. #Embedded #CProgramming #Firmware #BitManipulation #LowLevel For more details, please refer to the following article:

To support our growing user base, we have created a series of Riviera-PRO tutorial videos about transactions debugging.   •            #UVM Transactions Debugging. This video goes the tools within Riviera-PRO that can be used for debugging UVM transactions - tools such as the UVM Graph, UVM Hierarchy, UVM Configuration, Transactions Streams, Call Stack, and Covergroups. https://lnkd.in/e3KuqbvY   •            #SystemVerilog Transactions Debugging. Riviera-PRO provides a number of tools for transaction debugging. This video demonstrates them in use on a SystemVerilog design. https://lnkd.in/efddwQGH   •            #VHDL Transactions Debugging. This video demonstrates Riviera-PRO’s transaction debugging tools in use on a VHDL design. https://lnkd.in/dZmfr86e   •            #Assertions Debugging. This video covers all the debugging tools you can use for debugging assertions as well as reports that can be generated for post-simulation assertion analysis. https://lnkd.in/e-fuXhBi   Follow us and be sure not to miss out on notifications about other tool tips, product launch news and upcoming webinars. #debugging #RivieraPRO #DigitalElectronics #EDA #EmbeddedSystem #FPGA #FPGAdesign #FPGAdevelopment

Been diving into Serilog recently, and wow… logging in .NET feels so much cleaner and more powerful with it. Instead of drowning in plain text logs, structured logging makes it easy to filter, search, and actually understand what’s happening in your app — whether it’s in development or production. I hooked it up with Seq for visualization, and debugging suddenly feels a lot less painful. 🚀 Sometimes it’s these ecosystem tools that make you appreciate how mature .NET has become. 👉 Curious: what logging approach/tools are you using in your .NET projects? #DotNet #CSharp #Serilog #DeveloperTools #CleanCode

Using an RTOS = adding overhead. Maybe this is acceptable for your product, but the decision to use one should not be made lightly. As with most things in engineering, there are tradeoffs.