Hello and thank you for joining Teledyne LeCroy today. A few housekeeping items before we begin our webinar. To keep us running on time, we will hold questions and answers at the end of the webinar, but feel free to submit your questions as they come up using the questions section of your control panel. This webinar is being recorded. A link to the recording and slides will be sent automatically to you via email within the next 24–48 hours.



Finally, upon exiting today's webinar there will be a short survey that pops up. Please take a moment and answer these five questions so that we can continue to provide valuable content to you. For those of you just logging in, thank you for joining Teledyne LeCroy today for our webinar entitled Debug Embedded Systems with Your Oscilloscope presented by Steve Murphy. This is the third and final session of our new three-part webinar series. Today's session will focus on applying the principles we've learned into practice with a few real-world examples. Just a little bit about Teledyne LeCroy before we begin.



LeCroy was founded by Alabama native Walter LeCroy in 1964. Our corporate headquarters is located in Chestnut Ridge, New York, but we have sales and service offices all over the United States as well as the rest of the world. We started as an oscilloscope manufacturer and have branched out into protocol analysis through several compatible acquisitions. In 2012, LeCroy was acquired by Teledyne Technologies and we were renamed Teledyne LeCroy.



Our presenter today is Steve Murphy. Steve is a field applications engineer here at Teledyne LeCroy. Steve is based out of our corporate headquarters and has held a variety of roles during his 25+ years with us, including all things sales, marketing, and application-focused. We know there are a lot of demands on your time. We appreciate you spending this hour with us. I'll now hand things over to Steve to begin.



Thanks very much, Hilary. I appreciate that. And I would like to add my welcome to everyone to our webinar entitled Debugging Embedded Systems Using Your Oscilloscope. This is a three-part webinar. This is part three within the series. Our goal here is to improve your knowledge and your efficiency using an oscilloscope for validating and troubleshooting the interactions within an embedded design of the different signals that are found there: analog, digital, serial data, sensors, altogether. And their interactions is what we want to focus on in this webinar.



Again, this is part three. We covered in parts one and two about display measurement, waveform, math, and functions and all those tools for each of those categories, and now we're going to apply those to specific application examples.



However, I'm going to do a recap. This is the agenda. So I'm going to recap very briefly on parts one and two because we're going to use those tools to focus on the practical embedded design application examples here. And there are four of them here from power rail integrity. Just a thing on discussion, probing. Very important in that environment. Power rail sequence measurements. Low-speed to high-speed correlation within embedded designs, both internal and external communication. We want to see how that interaction plays out. And then we want to look at correlating sensor signals with embedded data. And we'll do a summary at the end. And then we'll take your questions at the end.



That's the agenda, so let's go ahead, let's do a quick recap for parts one and two.



So, the terms that we used in this webinar series is embedded system. What we mean by that is a standard embedded design is a fixed-function, self-contained control system on one printed circuit board. It's got lots of devices on it, depending on its complexity. So it could have passive devices, active devices. You can see analog, digital signals, serial data, and then there's a processor, so a device on board to process all the data and control the activities of that embedded design. And then it's got some memory of some type that could be within the device itself if it's an MCU. And they always have power-related things, so we need to understand power. And complexity could be really low to high depending if you have a washing machine, I like to pick on that. That's a real specific embedded design, right? It's got a specific task to do, and it's got a specific complexity, not real high cost, fairly low, size, relatively small, Internet of Things, I think about as other embedded systems because there are all kinds of those different functions. And so that's what we say is an embedded design with all these different signals.



When we add additional computing, then we call it an embedded computing system. And we're adding in a microprocessor beyond the microcontroller and a lot more processing. Memory is external, and we do have a lot more code for this particular design due to the computing nature. And then we focus now also on deeply embedded systems where we have pretty much everything that we've seen up above there, but we are also, now we have sensors that are sampling and getting data or talking to the environment. I like to relate this to a vehicle, and that we have some autonomy that's designed into the vehicle, but we take all the sensors around the car, whether it be radar, lidar, cameras, and then we process this data and we make decisions for the programming and then we control through ECUs and control the vehicle based on the design. So that would be a very deeply embedded system. Lots of computing going on in that example.



This is a block diagram. It's a representative of an embedded system, of a deeply embedded computer system. And what we want to do is understand the relationship that causes and affects the problems between various signals within this design. And you can see the color coding here. Analog is green. We have digital signals. We have power. We also have mixed signals. We also have serial data. So there's a lot going on as you look through from power and buck-boost, DC-DC converters, and management of powering up memory and controlling memory, controlling the power management IC, talking to the outside of the device onto the board, and then there's also high-speed serial data that is communicating to, not just on this microcontroller and this embedded design, but maybe to a motherboard or other devices or products outside. And we can see that here.



At any rate, the point is that there are lots of signals and we want to understand the cause and effect relationship of our design. And we want to validate it's good or find problems. Now an oscilloscope is one of our important tools to help with that debugging and validation process. And the application of what you're doing and how big the design is, will drive when you purchase a scope, how many analog channels or digital channels. The signals that you're trying to capture could be low-speed or high-speed or have fast edges and high-frequency content, so you'll need an analog bandwidth spec on the scope to support what you're trying to measure. Then you're going to tie that in with more sampling to support Nyquist so you have at least 2.5 to five times more than the bandwidth of the analog signal that you're trying to capture and measure. If you're really looking for good accuracy and amplitude measurements, then you're going to want to pick a scope that has higher dynamic range, vertical resolution, up to 12-bit. And you can post-process that to higher, your bandwidth will come down. But at any rate, keep in mind the amplitude-driven specs of your design will drive the requirements of your oscilloscope purchase for dynamic range. And then short memory, there's 10 M, and now when you want to look at wider time windows with this low-speed and high-speed interactions with an embedded design, we're going to need to call up some more memory in the scope to maintain the horizontal timing resolution and accuracy. So that's really what's going on there.



And with our tools, we've looked at four different groups: signal display tools, measurement tools, math functions, and then application-specific tools. We've got a color coding that we established through the slide set, and there it is. And then there is that, I'll call it a bar, the sliding bar here. And that was because when we looked at the usage model of all the different tools that are available with scopes. We looked at the tools and which tool we use as representative of whether we just need visual tools or we need analytical tools. Meaning, if you have a signal like this, this is pretty easy to see. You can even just make your measurements with the grids or with the amplitude and timing with cursors. But then when you look at something like this, a wider time window, we have no details of what's going on in that signal. And so we need analytical tools to understand what is happening with our data.



So those are the four groups down on the left side, and what we did in part one and part two was go through you can see on display tools and persistence and multi-grids and slicing, we did some eye diagrams. We also on measurement tools, we used cursors, we also used parameters. And, we did some pass-fail testing. And we used, we started to tie in some math functions with the parameters. And I'll show you that here as a summary here. I'm going to go live in just a moment. And then we talked about some basic math tools and what that does for us. And then there are more tools to get us into the analytical. These are all the ones that we are going to use today. If you would, go ahead and allow me to go live here.



This is an example. Let's just go right to the oscilloscope. And first to do that, I'm going to go to my camcorder. So this is me, live, at my workbench here. I do have a WaveRunner 8000HD oscilloscope here. That means it's 12-bit. This one's an 8-channel scope. And it's PC-based, so I'm running my camcorder through this. This GoToMeeting webinar is hosted through my browser that's tied into my router here. And, I have PowerPoint running. And, I also have the scope application, of course, running here. So this is my setup. I do have an 8-bit microchip PIC here that's being powered by USB. That's going to be a source. I do have my microcontroller here, my embedded designs here. And I do also have today another device here, which has four micro power modules. It's got a power management IC on it and eight outputs, and I'm going to power it up with my power supply here. And I do have an electronic load and multimeter and all that. So this is my workbench that we're going to do. I like to try to have this be as live as possible, and not just totally slide. So you're going to see me bounce around, but all of this is being done on the oscilloscope. Okay. So this is the scope application that's running, you can see here we go.



There. So this is the scope. Let me bring this back down. And as a summary, as I complete the summary, I did want to point out let's go live to do a summary of some tools. And so, what are we looking at? We're looking on channel 4. This is a pulse-width modulated waveform. We're capturing it. Always look for the sample rate and the time-base here that you're looking at, and the memory length and the time-based descriptor. We're at 2 ms/div times 10 divisions is 20 ms. Just capturing at 100 MS/s, not real fast. We're using 2 million data points across that 20 ms. And we've turned on, we did use cursors to really understand what was going on too, but that's time-consuming and not as precise, remember? So in the tool section, we then called up these parameter tables. I've got amplitude and frequency and duty and rise and frequency. So all of those are being captured. And if I clear sweeps, I do a single clear sweeps, reset, and just do a single shot. We noted in part one that every width I'll pick on P7. Every width is being captured and put into the statistics table. We have 196 is the average mean. The last measured value is there. And then we're 157 ?s.



And, I'm just going to let this run. And, again, just to be brief, we can see also that this is now the average mean is 196 ?s but we have ns is the smallest and the largest is 241 ?s. So there's some, the range is quite different here all of a sudden. And when we look at the distribution of those measurements, we can see in the histicon below, and every parameter by the way has this turned on, there is a little outlier. This represents zero width all the way to the right as wide width. Most of the measurements, I would say, are in this 198, 197 ?s region. And we do have an outlier that's 166. That's highlighted here by this bin, which is closer to zero. So that gives us an idea that, for sure, the distribution of the measurements is grouped except for an outlier. And we can also see this with rise time. Amplitude is a complete waveform measurement, so we are capturing 400. Let's just go ahead and stop this. Let's do single. We're going to stop this. We have 419 acquisitions and 21,000 widths here.



But what I'd like to do is now, a summary, remember we looked at some tracks and trends in histograms. So let's just do a very quick on that. I'm going to use math function F1 to do a track. And, again, these are every value. Let's do a single absolute. Every value. This width right here is measured as 228 ?s. And then this next positive width is over here. This one is a little lower. That's 191 ?s. And we can see that every value is calculated now, and plotted as a math track, and it's time-correlated. Sometimes folks believe this is a waveform, but it's not. It's not an acquired waveform. It is a calculated, analytical tool here that we should make sure that we utilize in our embedded design debugging. So I'm pushing and doing a single shot. I'm not triggering on the glitch, but I know it's there. And let's just look for it. And there. In fact, there are two of them. So we see here that there are two issues.



Since we know it's time-correlated, in fact, if we just do this right, we can see that the values of each width is plotted and held until the next measured value. And we do have the glitch here. We know right where it is now, and there are two of them, but let's just focus on this one. Now, let's go to display auto grid, and then we can now see that this is the time correlated, Z4. Yeah. So that is the glitch. I didn't zoom both of these, but there's the glitch. So now we can see where the glitches actually occur. In your embedded design, have other channels turned on, whether they're digital or analog. Doesn't matter. But then now you can correlate this glitch and these two glitches actually with what else is going on. What caused that or how does this affect your embedded design? I'm just going to flick that off. And, back to P7 with my mouse, I'm going to do a trend because I wanted to point that out. And I'm going to also, since I'm here, just do a histogram to do my summary. Okay.



So, I wanted to point out here that, what is a trend versus a track? A track is time-correlated. A trend is not. It is an accumulation of the measurements, again, of P7, this width. And we can see the two glitches definitely show up there, but the scale's different because it's on measurements per division. And if I go in I'm going to, and then okay. So that's the trend. Let's just keep that thought. I'm going to do another single shot. And you can see that since we are at 100 measurements per division, we now have taken the first acquisition that had the two glitches, saved the data, moved it to the left, and acquired more data again. And so we can see there are no glitches in this, and I see in the track, for sure, it's not. So I'll go grab some more. Oh, there's one. Yes. So there it is towards the beginning, and we can see it now that it also shows up. So this is a history of three acquisitions and all of the measurements of P7. This is showing you the glitch of, this is the track of the last acquisition that has been stopped, and this the glitch is actually hiding in here. So tracks are very useful to help us find things. Let me just explain this. This is the histogram that is the same as the histicon. And if we take the cursor I'm using my mouse here, putting it over here, and we can say that, hey, this it tells us the bin width. The bin height tells us that there are three measurements here within, whenever I did reset here, within these number of measurements, this bin says there are three outliers. And so we remember, there are the three right there. We could put a cursor on this too and make the measurements as well. So this is a track. This is a trend. This is a histogram of the P7 data. And so if I go back to the PowerPoint to move along here, this is just what I took you through live.



The signal, the track, the trend, the histogram, all built from the P7 waveform. Remember, I only have one channel that's live. That's channel 4. These other three traces and math functions are all math functions, not live waveforms. I'll point that out as we go along. Okay. So you'll get this slide set. And, yeah, there we go. Also, as a summary, we did cover math tools. I picked on four of them. I also picked on FFT in part two. And these math tools, lots are available, and we're going to use these when we do debugging and validation of our design, we'll want to utilize these. And what we did also, as I wrap up the summary, is the trigger and decoding of serial data. And there's lots of protocols, and when we tell the scope what the protocol is, we can colorize it, annotate it, provide it in binary hex or ASCII or even symbolically on using Controller Area Network (CAN) protocols. Anyway, so we can decode, we can set our reference point to be not just a channel for triggering but also serial data. We can define using the protocol where we trigger. And then we can also bring in a mixed-signal, a digital lead set to capture, in this case, eight channels, and then we can decode and provide the bus view the values of these. But it's also a trigger. And so we can trigger on this zero this pattern we can see across the bottom. We can bring in analog channels, and we can and, or, nor it and do a little boolean. Anyway, there's lots of functionality we could also call in as we debug our embedded design. So that was a quick review. Let's move on now to practical examples.



There's where we are on the agenda. Okay, example one. This is focused on power rail integrity measurements and probing power rails.



Okay. If we look at our block diagram, our representative block diagram of deeply embedded design, we can see that there are power rails throughout this computing system here. And really, we are taking, in this case, see 12 V as an example, and we are converting it using these DC-DC converters to be usable for the next device, whether it be low dropouts, to power up memory devices, or DC-DC converters for other things or even DC boost, so buck-boost converters. And so they're all through our design. And so we are going to analyze the quality and integrity of these power rails. And the way we're doing it with our oscilloscope is, using let's get this example. We have three channels turned on. Channel 1 is a 900 mV rail. Channel 5, which will be our focus actually, is a 1 V rail, and we have a current probe channel 8 here showing the 4 A/div that is. Okay. So we got about 20 A of load, and we are looking that on this channel 5 that there is, when we are at high sensitivity, so we are at 7 mV/div, we can see the ripple both before and after the load change, but we also see the minus droop. And these are the measurements we really want to make. And what we'll do, we could just do that just looking at it with a scope. You don't need much software tools to do that, analytical tools, for this part, for just real simple designs. But when it starts to get more accurate measurements and your tolerance levels gets lower and lower and that you don't want a lot of noise, now we're going to use the scope's analytical capabilities to give us more insight.



And so this particular, I'm pointing out here, our digital power management application software to simplify your analysis, and it really helps simplify some really good details. Channel 1 is also a rail voltage, and all of these rails have switching frequency from the pulse-width modulation of the switching devices that appears on the output. We're going to use that switching noise, that switching frequency, as the basis for making power rail measurements. So every switching period, we'll make a measurement and build up a table. So let's do that. So that is our source. And instead of just using a parameter table from our standard measurements, we're now going to use the switching frequency, the synchronizing sync signal, to give us a per-cycle, for each of these cycles, measurements within the power measurement table. Things like RMS, mean, plus peak, peak-to-peak, are being measured now on the voltage rail, which has been set to be this 1 V. We're also showing you the current rail, which is this. But let's focus on the voltage rail. And we're seeing on a per-cycle basis, we're going to make this measurement. And now, this is the mean value across the entire waveform of channel 5.



Okay? So that we're seeing a 990.6 mV mean across all of this, but it includes the droop. Let's dive into this a little bit further. Let's now turn on zoom and gate. And now the zoom window defines where the measurements are being made and applied to this table. These are still mean values, but now they're only the mean values of the zoom. The zoom is shown here to the right of this area of our channel 5. And so we now see 999.66 mV is the mean, and we're looking at a 19.47 mV peak-to-peak noise in here. So that's being occurred. That's where we're measuring it. This is the no-load part. So let's go to a load condition, and that's off here. And so we have a new zoom showing you a different area. And look at our measurements now. Our mean value is higher, and our peak-to-peak is a little noisier, 21.54 mV during the load. So we're using, again, these measurements are from the synchronization signal, which is that channel 1. And it's a per-cycle measurement of each of these values. And this is about to be plotted. Watch. Here we go. There it is. And so these are the mean values. I just touched that cell. We then show you this is the per-cycle basis. This is the mean through the entire waveform now because this is not zoom-gated in a particular part of doing the whole thing, and now we are showing you every mean value. That's the mean displayed one. And that is, you can see every individual value here. But let me do this. I'm going to go back to my power management.



This is a Linear Technology micro power module. I get four of them, and there are eight outputs, and I've got probes on each of those. Well, we only want to look at one. I'm going to that was my source for looking. Let's go up to file and recall the LabNotebook. I am going to just browse to a folder that I used for preparing for today, called the embedded part three, and I'm going to look at this. I'm going to flash this back. So we are using the scope to store traces right now just to support the slide set. And there's the waveform, and I'm doing this. So what have we got on this particular we're using C3 in this case is a 1.5 V rail. We have a current probe in that we're our this is the load. I used the electronic load here to give us about 6 A here, 1.5 A/div. And then we have the per-cycle waveform that came in from channel 1 that was acquired simultaneously like the slides. And we can see the green, no color, green, no color. And so this is showing you the cycle, the periodicity of channel 1 through all of, and showing you the actual measurements. So I'm happy with this cyclical nature of our synthesized waveform that is being used as the source of this parameter table, this measurement table.



And what we have is now, we're looking, we're not gated. We're looking at the entire waveform. And we turned on, we touched this right here, this cell right here, to give us the mean. And when I put that up here, we can see that we measure whatever value is being displayed. In this case, I'm focused on mean, during each one of those switching cycles that's on channel 1. And it's 500 kHz, again, right there. So this is our waveform. And then when we put it over here, we can see the actual measurements of droop, and the minus peak now can be made on this per-cycle mean waveform. And then we can do some pass-fail testing on this. I'll show you in just a sec. But that is the minus peak. And what's really what I like about being able to do it that way is we want to know the mean value. We want to know the minus peak, which we can, which is actually displayed here, right there. And, one point, minus peak is 1.4639 or .4. And so that is showing you that minus peak. But the recovery time is calculated from the mean prior to the load, after the droop and the load. Within 10% of that value, we want to measure the recovery time. And so we need these mean values. It's so much easier to do it with this per-cycle waveform. And then we want to know the recovery time from probably we can just turn on a cursor. And we could do the cursor, just, I'll do relative. And it's already there. So this is our trigger point. We'll just say from here to this mean value. It can be just like right here. We can see that the recovery time is 23 ?s, and then, the oops. Wait. I moved the wrong one. My bad. Let's go back down to here. This is where we started our load. And then I'll let me use the other cursor. That makes more sense, Steve. And then so that timing right there is 44 ?s. And then to reach steady state, we'll just put that here, to move things along. That's 57 ?s to reach steady state. But we're using the mean values, and therefore the DC coupling. So, at any rate, that is using some software tools that are available to you to make these measurements. This is a single rail. When we have more rails, then, well, the table will increase, and we'll make all of these measurements across all of those rails that we've acquired.



Okay. We're going to go back to the PowerPoint. This is showing you what I've just taken you through effectively. And then when it comes to probing power rails, it's a challenge because the probes, the power rails themselves are low impedance, but we do have challenges with how to probe that. So, this slide has a lot of info on it, and I'll just pick on some of those. Again, use the slides when you get them as a review. There's a seminar just on this topic right here. As an example, when you're probing these power rails, RF pickup is so important. I'm sure you've run into it already. These 10x probes have these inductors right here. This is a ground lead with the alligator kit. This picks up too much noise. Look at that nice loop here. Here's a nice loop, and that's going to just pick up noise. So we don't want to use that. Use the spring adapter on the end of the probe to do that. We want to stay coaxial all the way to the test point as much as possible. To do that, let's do this. There are these lead sets here. This is basically 50 Ohm, and we would just solder this probe tip, the center conductor, to our output capacitor and then the ground, the shield, to ground. And then this little thing can be connected right to your 50 Ohm cable as we see here. And this is just a little adapter you can get. They're pretty low-cost. Just plug those in here. It goes right, and then you would go to SMA to a BNC, if you will, in this case, or you can go straight into a BNC. There are those adapters available. Now you've got straight into the scope. Very good, and you're connected, you're soldered in, no impedance, no RF pickup. So, there's, again, there's a whole webinar and topic on this stuff.



Noise is another one I like to pick on. 10x probes attenuate the signal. So if you have a very low tolerance for ripple and noise, then you're going to amplify. You're going to look at that and increase the sensitivity, and amplifying noise, and so you're going to lose 20 dB of signal-to-noise ratio. So that's not good. And then if you're using a 50 Ohm cable to eliminate that 10x and go to 1x, then, if you are looking at voltage rails higher than 5 V RMS, then you've got to go to 1 MOhm on the scope. So you have a low impedance of your circuit to a 50 Ohm cable to 1 MOhm, ah, that is an impedance mismatch causing a reflection to the signal go back to the circuit, to zero, and then that's going to reflect. So at any rate, if you're under 20 MHz, I say here, as an example, then that reflection's going to be minimal to you. But if you are interested in seeing anything greater than 20 MHz, then you have a better solution. Go to 50 Ohm, but if you go to 50 Ohm on the scope, then that low impedance, input impedance of the scope with the low impedance of zero of your power rail, If you have low current circuits, then the scope's going to be pulling like 60 mA within into the scope. And on a 3.3 V rail, that might not be good. But if you're dealing with high currents, then that's not such an issue. So there are considerations all the way through here, and there's again, this is a whole webinar and conversation by itself. I've given you comparisons and trade-offs here with five different probes and against many of these considerations of these other topics. And so there's red is bad, green is good, yellow is okay. And so just go through this, and, of course, oscilloscope manufacturers do have power rail probes, and that really gives you the high impedance at DC and low impedance for high frequency. So these probes can go higher than the limits of other solutions. They don't have the reflections because of that impedance management. The offset range is much better at the higher bandwidth, perfect for loading, as I already mentioned. So, at any rate, these trade-offs and just things to think about as well.



Let's move on to example two. This is about rail sequencing. So, when we take 12 V and we convert it to a usable by the devices within the design or within the embedded computing system, there's buck-boost converters, and they can all be turned on at once. And before you do main power and do all of the other designs, what the system was really designed to do, first, you got to turn on particular things on the board, and then you can turn on the main power as an example. So we want to see, are the rails ready in the time that we expect them to so we can go to main power? And so that's really what our process is here in this slide set. We're going to push the power button. We're going to make sure that the power rails turn on in a specific defined order within limits, of course, and then we're going to turn on the main power. So we want to test all that.



So to do that, let's just say we don't need to look at ripple. We don't need that high dynamic range. We want a scope. We're just looking at the signals, and we're going to look at all of the rails. And it is fine. You can take a look at this area. We're going to use cursors in a moment, and we're good with that. And we can look at the timing. So let's just do that. So here is a zoom of that area. We've got four rails, and we want to measure the timing. This time, we're going to measure this delay between each of the rail startups, using cursors. We see we're at 5 ms there, and then these two, it's 7 ms. Our goal was to have it within 10 ms, so we're doing fine. This one is this here. We can see we're at 5 ms, and then these two, from the start to the fourth rail is 17 ms, and we're good with that. Now if we shut off and turn on, will we be in line? Will it always be that way? Will there be any outliers? Now we're going to start using parameter tables to do that. So we're going to use P1, and we're going to do tools and measurements like delta time at level or delay, whichever. And so we're going to make measurements of this, and we could increase it. In fact, I might even go live with you on this, but we can increase this, increase the number of measurements so that we can measure different rails, and then we can do the pass-fail testing on each of these parameters that we talked about on part one. Let's just go quickly. Remember, we're back at my power rail here, my Linear Technology micro power module evaluation module.



Go to the scope. Let's just flash this back. Recall LabNotebook. Go right to here. I am going to flash this back. What I'm doing is taking my previous capture, replacing it with a new panel setup and new waveforms. And here we are. And let's go ahead and I'm just going to do it this way. Alright. And close this. So now the way I did it here is instead of a single grid, I left it with four grids. We can see channel 1, 2, 3, 4, and all the different voltage rails are being measured here. We've got 900 mV, 700.5 V, 1.5 V, 1.2 V rails. And now this is my point. This is the delay measurements that we're using from channel 1 as a reference point for all these measurements. And then we could go ahead and do the analysis and do pass-fail testing, here to make measurements of parameters and turn this on here for each of these. So at any rate this is an easier, more accurate way than using cursors, but you can still use cursors. Depends on what the accuracy is. And, also, these are just four rail voltages, but maybe we want to look at other signals in our embedded design simultaneously. So, at any rate, all these tools are available to you to help focus your debugging challenge.



There's the pass-fail testing, and then the action is, stop or save it to a hard copy. So that completes example two, sequence testing.



Now, on to example three. And this is low-speed event correlation to high-speed events. And so this one here, we're going to look at, our low-speed event would be something like our ROM BIOS and flash memory, programming the microcontroller, And then with that data, then now the microcontroller will go and interface and talk to a through PCIe as an example, some high-speed serial data will talk to a motherboard. So first, we got to do the low-speed stuff, and then now we've gotten that programmed, and then now we're going to be able to talk to an external motherboard, just as an example for this. So to work with low-speed and high-speed, we've got to just draw attention to the time base on the display. All scopes have this. And so you have the record length, which is the 500 ms/div, and then we have the sample rate, 10 MS/s in this case, and then memory is 50 million data points. So in order to determine how much memory you're going to need, we'll take the sample rate, in this case 10 MS/s, times the time per division, 500 ms, and of course there are 10 divisions. And then that little formula gets us to 50 million samples as the needed acquisition memory with this. So when we apply this, let's go to look at low-speed events, high-speed events, and then we're going to want to see the interaction of the low with high-speed. Therefore, we're going to point out that memory is required.



When we look at low-speed events, the sample rate doesn't need to be very fast, so it's low. With the record length, because it's long and slow, we will need to have more time window. And then the acquisition memory does not have to be as long because our sample rate's really not that fast. So that's the process here with this slide. For high-speed events, you've got to have high-speed sampling in order to support the capture. The record length, just for the high-speed event, single event, is short record length, and the acquisition memory also does not have to be real long since everything is short. But when we're looking at the combination, in this case, when we're looking at something coming in from our mixed-signal probe, and, we're going to then capture PCIe data as well, and we want to know the timing between those two, and still see the data for both protocols, more on that in a second, then we do need to have a sample rate that supports the high-speed part of the capture. We have the record length that needs to support the whole time window and the so that would be the time per division setting. It's going to have to be much wider now due to the combination of the low, which really sets the time window. And then the acquisition memory, is therefore we're going to need a lot of data because of the requirements for high-speed plus a wide time window to see the low-speed event and with the high-speed. So there is a summary of all of that showing you that those three cases don't require 50 million samples versus here, we're going to need 5 G of data to see all of that. So we're looking at sample rates at 10 MS/s, but that high-speed, though, is really 5 GS/s or faster to see fast data transfers like, example, PCIe or the faster USBs.



So what are we doing? We're going to be measuring when the power button is pressed. SPI data is being programmed to flash. And, so that's a low-speed protocol, but then the motherboard communicates with the microcontroller via PCIe within 250 ms. And so we want to measure that. So to do it, we're going to do a mixed-signal. We're going to capture the low-speed. We're going to save it. We are going to, there is the navigational reference where our trigger is. So let's just point out where that is. So right here on the display, we can see we're at 50% pre-trigger, 50% post-trigger right now is our trigger, our zero delay. That is the default setting now typically on oscilloscopes, you can move that left or right, but we are triggering on right here. D1 is our trigger, and we're negative going edge. And what we'll do is we want to move that over to the left so we can see the low-speed SPI flash programming and the PCIe that is coming up.



So, this is showing you that if you change your time per div setting right now, that the reference point can be either the center here, as you change your time per division setting, it'll expand or contract the time window around the center versus if you're in a lock to trigger position, wherever you put that delay location, the trigger delay position, it will expand and contract the time window, time per division, around that point. So that's important to recognize, that scopes do these a little bit differently. That's what you would use as a navigational reference point for Teledyne LeCroy. But, so we triggered here. There's the SPI data, and what we'll do is we're going to zoom in on that. And when we zoom in on that, we see this SPI data, programming to flash. I may have said that incorrectly at the very beginning. But anyway, this is the flash program. So this is SPI low-speed serial data captured with your mixed-signal probe, actually, your digital lead set. And then what we'll do is we'll decode it. And working with engineering, they confirmed that the data that I was decoding here with SPI was properly set and that this is the data that is being programmed to flash. And yeah. And so capture the data, clock and data. We decode it, and there's the decoded data. This is using software tools.



Now as we've confirmed we're happy with decoding that, let's go ahead and capture a wider time window. Look at the right. We are now at 20 ms/div. We're now sampling at 20 GS/s. We are looking at a trigger off here. This is the zero-delay location. This is where the SPI flash programming is occurring, and then this is the PCIe data, here being transferred with the motherboard. So, to see this and to decode this as well, we need fast sampling, so we're at 20 GS/s. We're using 4 G of memory for this 20 ms times 10, 200 ms, or a fifth of a second worth of data. So high sample rate requires long memory to maintain that sample rate over that time window. So that is an example of an embedded design. The takeaway here is, the faster data requires faster sampling. The low-speed to see those simultaneously with your high-speed to confirm that you are within the 250 ms design requirement to talk to the motherboard through PCIe start, we need to see the whole time window. And therefore, fast sampling, long time window equates to long memory. So that wraps that example of correlating low-speed to high-speed serial.



Okay. Now let's go on to this example four. And this is now what we're going to do is we're going to take a look at some embedded sensor signals and the interaction with a pulse-width modulation controller in this embedded design. So we're going to look more on this side of our representative block diagram of our embedded design here. And so here, just to jump to it here, the problem statement, what we're trying to do is we're going to look at this embedded design is monitoring the temperature. And based on the result of the temperature, we're going to vary the fan speed to cool down or not to save, or to sort of increase the speed or lower the speed, depending on what the requirements are of our device. And so we're monitoring the DUT with a microcontroller, and as the temperature changes, the microcontroller algorithm determines what the width should be for the fan control and sends out that command. The microcontroller talks to the pulse-width modulator controller, and, you'll see this is going to be with I2C, and determines which fan speed should be faster or slower.



Basically what we have is we capture a signal just using a real simple probe, and this is the voltage we'll be monitoring as the temperature drops or rises. We can see the resulting waveform here. We are going to turn on some bandwidth limit because it is a little bit of a noisy signal with our high-frequency measurement system here. And then we want to see over time how the temperature is varying to start with, because then we're going to need to control this fan as a result of this signal. And so we can see we're at 5 s/div, which time stands, so 50 seconds worth of time here. And we don't need fast sample rates for this. And I'm showing you an example where the sensors were able to acquire this signal, but it's not always the case. So, for this example, we are going to have it be available. And what we're going to do is that there is I2C communication from the microcontroller to the pulse-width modulation controller that's driving the fan. So as the temperature varies, the microcontroller tries to adjust the fan speed by increasing the RPM, and so we are looking at I2C messages. We have the clock for I2C and the data. And embedded in this data is the command to the PWM controller. And so that's what we want to look at. We're going to want to extract that and compare that to the actual temperature. And so that's where we're heading as we look at this 50 seconds worth of data.



And so here we're looking at, we're going to extract the data, but first we're going to decode it. So we're going to tell the scope I2C, channel 3 and 2 is where the clock's coming in. We happen to use just standard, single-ended probes for this. And then what we're doing is and so there are lots of protocols that we can extract. The oscilloscopes have, depending on the options that you purchase, all kinds of choice available. And what we're doing is we're going to take the data and, we're going to decode it, and we're going to, since we're looking at 50 seconds worth of data, we can't really see much of the details of each of the messages unless we use the protocol analyzer type table, where we're looking at the time from trigger, the address line 7 or 10, the address and the direction, whether it's read or write, and the number of data bytes is listed here, and then the data is listed here. And so that is down below the waveform grid and listed in this table, and you can expand the rows to see more details, if you would like. Okay. So, that's the data. And then, what we'll do is, since we really only want to see the data being sent to one of the output, there are really three of them. I think that was on this previous slide. Yeah. In this example, address refers to the pulse-width modulation controller ID. So the address is 9A, and then there are different outputs. So we're looking at hexadecimal 30, 40, and 50, and that refers to the different outputs in that part of the data field. And what we're going to want to do is we want to look at address 9A, but we want to look at only one of the outputs, which is hexadecimal 40.



So, what we'll do is we'll filter the table, so we're only going to display the data from that location. So that's what we've just did. We turned on the filter. There'll be a little caret that is displayed that shows that indeed we have a filter turned on. At any rate. So now we're just looking at just with the data 40 to that particular single output, and that's what we're really interested in plotting. So we're going to use a parameter. We're going to pull out the data, from a particular address 9A and the 40 output. So that is the requirements. We're going to say, okay, let's use the message to value. Let's go ahead and data to extract. Let's start at position seven in the data field, and we want to grab eight bits. And then now that we're going to take that for all of that output to address 40, that output, We're going to look at that data, and then now we're going to convert it so that it's usable. Remember, it is temperature that we're trying to understand. So then we do a conversion oh, no. It's speed. My bad. So it's 14.11, and we're going to convert that value from this data field, that part of the data field for that particular 40 output, and we're going to convert it to RPM. And so that is showing you, here, this is the dialog menu open. And these are the controls for that message to value conversion. All right, so that's what we're seeing and expanded on, here. Okay.



So what we basically are doing is we decoded the I2C data. We are looking at only address 40 by filtering it, the output for one of the three outputs, and then we are plotting the value and converting it to RPM with the conversion factor we showed you on the previous slide. The result is not an acquired waveform, but a calculated track. Here we go. This is what we talked about in part two, but this is now a track of RPM that then is extracted from address 9A and only from the hexadecimal 40 output. So that's now the shape. We could put cursors on that and actually measure it and see every one of these values. Look on the left. We can see the RPM conversion results of this waveform over here. So as the temperature goes up, the RPM is increased by the controller. We want to now look at that PWM controller and look at it live with an actual channel 6. So we're going to acquire channel 6. The passive probe captures the actual PWM versus we're looking at the embedded data controls of the I2C message. And we want to compare those two. So we set up the parameter measure duty cycle. So that's where we are down here in P2. We're going to measure duty cycle of C6, which is the actual live analog capture. And what we're going to do is we're going to track how duty cycle changes. And so and that's what's used. That's what's spinning the fan.



So we set up the track for duty cycle, actual, and then I'm showing you a zoom right now of just one little slice in here to show the pulse-width modulation, that is the motor voltage. That's the output to the motor. And what we're doing now is we're comparing the pulse-width modulated track of the live signal that was duty cycle, and now we're comparing that to what was the message that we sent out to the PWM controller. And so that is the track of the decoded 9A, this was, and output 40, and the values that were changed, that were decoded. And so indeed, we do see the output to the PWM controller live versus what was decoded matches when we put those on top of each other, and they're perfectly aligned. So this is just showing you the use of extracting I2C data in your embedded design to validate, to verify the interaction between analog signals that's driving that fan versus decoded, versus I2C embedded data that we've extracted, again using tracks. And they're not waveforms again, they are actual tracks, mathematical values here. RPM versus duty cycle example is what we did here. Okay, that is the and by the way, the mixed-signal, the digital lead set can handle the I2C clock and data, so that'll save your analog channels. And there are lots of other protocols that you can be doing this well. This is just an example.



So, definitely gives better insight and helps complete the validation with these tools. I had one more example here, and this is CAN bus. I put this here because same thing, CAN bus data, CAN bus particular ID, and a particular part of that ID and of the data field, we extract that and apply the, and use a parameter like we're using CAN to value here. And we can get the embedded data. We go ahead and set up the scale factor appropriately and any offset that's needed so that we get angle of rotation and speed can be extracted from particular CAN messages. In this case, I think it was steering wheel rotation, and we were doing the angle of rotation that we were measuring here and plotting across this 500 ms, across this 5 seconds worth of data. So, again, just another example of embedded design using these extraction tools.



Okay. Definitely analysis. Analyze. When I compare the visual versus analytical tools, those are definitely useful tools. Make sure that your oscilloscope that you either turn on the option or if it hasn't, you utilize this as you debug and validate your embedded design. So we covered a lot here, and I appreciate all your time, your interest, and we went from all kinds of signal display measurement, so signal tools or display tools. We did measurement tools, we did math and analysis, and then we had four examples. So we've covered quite a bit here. I hope you found this useful. This webinar will be stored and available to you to view on demand. We'll actually be sending you the link. And this is the website. Go to teledynelecroy.com/events to get that data. And this is part two and part one, anyway, for then part one was the display and measurement tools. So, anyway, they are available back on-demand. There also is everything that you saw me on the screen images and me working with the Scope Live. You can download the Scope software application for your Windows PC and run it on your PC remotely. You don't have to own a scope to do it, and you could work with some of the LabNotebooks if you want them. Just let me know. I'll give you my email address, but there are LabNotebooks available. They just download the software, install it on your PC. Let us know what your serial number and ID is so we can send you back a license. And once you just double-click that license, then you'll have access to all kinds of options that are automatically turned on, and you can work with the scope application remotely.



Okay. So, now I'm going to again, I want to say thank you for your time, your interest. We went just a little bit over. But again, I do hope that you found this useful. And I'll now turn it over to Hilary. So thanks everyone for joining us.



Thanks everyone for joining us. If you have any questions, go ahead and throw them in. I know we ran a little bit over. We appreciate you staying with us. I'll be sending out a link to the recording and slides, and I'll also include a link for the other previous sessions. We do have a lot of webinars coming up. So I'd invite you to join us again online soon. And if you have any questions, you can email me directly or Steve. So thanks everyone for joining us. Stay safe, bye.