In my last blog, I reviewed the difference between Run-Control and Trace, as two powerful debugging technologies. How are they used together to dramatically improve the chances of catching an intermittent bug?
Boundary-scan test is used commonly on manufacturing lines with a “benchtop” tester, complete with cables, fixturing, hardware probes, and so on. What are the pros and cons of embedding this technology in-situ?
Because of the inherent advantages of in-system programming over standalone programming stations, many design and production engineers have long sought to program soldered-down flash, I2C and SPI memory devices through the JTAG port on a connected device like an FPGA. The problems with pre-programming memory on a standalone station is quite often the contents of the device will change, especially if it's firmware or software. Without in-system programming, updating the stored data would require de-soldering, reprogramming and re-soldering. And the likelihood of damage to the device and board skyrockets.
Software and hardware debug, validation and test of complex systems has always been a challenge that’s demanded innovative new solutions. Now, one of the biggest challenges facing our industry is the disappearing boundary between hardware and software when it comes to finding the root causes of problems. Solving those tough problems is what ASSET InterTech is about, no matter where the problem is.
Intel® provides a collection of scripts (collectively known as Intel® Customer Scripts, or CScripts for short), which assist customers with platform debug and validation. Can they be made to run faster?
The good news is that the EDK2 software distribution continues to grow, adding features to better support the community. The not-so-good news is that the complexity of the EFI code has grown to take advantage of silicon features until it now looks more like an operating system than a BIOS replacement. That can be problematic for software engineers during debug unless they have the right tools.
IEEE 1687 IJTAG is winning great interest throughout the ecosystem, from chip to board to system, due to the manner in which it enables interoperability of embedded instruments and their tool chains from the early stages of chip design through to fully deployed systems.
Debate rages in the embedded software development community about the cost/benefit of using printf statements to debug code. With today’s silicon embedded intellectual property (IP), there is no reason why instrumentation can’t be used in conjunction with trace to provide immediate real-time insight into defect-laced code.
For years, the industry has been grappling with how to access, control and operate instruments that have been embedded in chips. The problem wasn’t that the instruments couldn’t be accessed. Instead, there were too many access methods, each proprietary or customized by the chip supplier. The IEEE 1687 IJTAG standard changed this. Not only has IJTAG standardized the access method, but it’s also widened the scope of re-use for embedded instruments. Rather than being limited to just chip characterization, test and debug, IJTAG enables re-use of instruments and their test vectors to validate, test and debug circuit boards as well.