SEGGER Microcontroller’s Post

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. ⬇️

At GSAS, we know how valuable deep visibility is when debugging complex embedded systems. That’s why we’re excited that SEGGER’s Ozone is now available not just with J-Link and J-Trace, but also with simulators and third-party probes—bringing advanced tracing, profiling, and code coverage to any Arm or RISC-V workflow ! Reach out to us today to learn more! #debugger #embeddedsystems #jlink

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

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

✅ Lower overhead in terms of latency / non-deterministic timers ✅ No scheduling, interrupt or priority handling complexity ✅ Direct access to hardware ✅ Lack of standard interface (APIs) means open to customisation ✅ Predictable behaviour (no tasks/schedule conflicts / eviction etc) A bare-metal OS is “better” than an RTOS for applications where simplicity, minimal overhead, and direct hardware control are critical, such as in resource-constrained or ultra-low-latency systems. However, for complex systems requiring multitasking, scalability, or standardized abstractions, an RTOS is typically more suitable unless there is dedicated micro controller for every peripheral 😅

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.