I2C SPI USB CAN eSPI Cable Testing View All Quick Start Guides User Manuals Software Downloads Knowledge Base Videos Case Studies App Notes White Papers Sales Support About Us
Products Blog Sales Support Contact Search
Easing the Integration of Embedded Hardware with Embedded Software?
Chris

Embedded systems.  Often the hardware is designed by one group and then handed to the software team to design the other half of the project. This can lead to assumptions about hardware functionality that may result in a difficult debugging process.

In the article Minimizing risk: embedded software and today's medical devices, Stephen Olson describes a specific instance where this problem of disconnect between hardware and software has occurred and describes how it could have been prevented.  In this case, the connectivity of a USB port failed causing data loss. All functions of the embedded chip were activated, causing it to send intermittent signals through the bus that in turn caused the host computer to shut down the USB port.  In essence, embedded hardware was overdriven by software.  The data was being collected from a patient who was being analyzed with a complex medical system. The system had to be reset requiring the patient to reschedule the appointment for another day.   It’s not hard to see why this is a problem for the end user – it costs time and money, our most valuable resources.

But why did this happen? The software had been written with the assumption the USB controller would never fail. The process of collecting data was directly related to transmitting data. The system needed the ability to actively store data while tracking the test, even in the event of power loss or system shut down.  But due to the assumption the USB controller would never fail, this use case was considered during software design.

How would you fix such a problem should it occur? Rigorous testing through a variety of use cases would likely have identified this issue.  What happens when an issue is identified with device operation but the underlying cause in unknown?  This is when debug tools, such as protocol analyzers, can become useful.  In this case, a USB protocol analyzer, such as the Beagle USB 480 Power Protocol Analyzer would have provided great value.

beagle480power-300jpg

We have worked with a medical device company facing a similar issue, only their problem was found during extensive lab testing.  They were seeing total shut down of the USB bus during certain test sequences but were unable to determine the cause, thus preventing them from resolving their issue.  In the field, there is little room for medical device failure or unexpected shutdown so fixing this problem was of the utmost importance.

After learning about the issue, we introduced the Beagle USB 480 Power Protocol Analyzer  - Ultimate Edition.  This tool is designed specifically to track both USB data transfers as well as VBUS power events.  This allowed them to correlate the bus shut down, power loss, with the data communication occurring at that time – allowing them to identify what test condition was causing the failure.  Additionally, the Ultimate edition has Advanced State-Based Triggering that allowed them to set up conditions and run repeatedly through tests until the failure occur.  At that time, the trace would capture the most recent set of data for analysis. Through the use of the Beagle USB 480 Power analyzer, the issue was identified and resolved within weeks, allowing production to move forward.

Wondering if a protocol analyzer or other development tool could help solve your problem?    Additional resources that you may find helpful include the following:

Do you have a problem to solve - or better yet, prevent it? Feel free to email us at sales@totalphase.com, or if you already own one of our devices and have a technical question, please submit a request for technical support.