Rigol MSO2072A problem, display stops updating

• Rigol MSO2072A problem, display stops updating
  Posted by esar on 08 Nov, 2014 18:01
• Hi Everyone
  
  I took delivery of an MSO2072A earlier this week, but I've run into a strange problem where the display stops updating the waveform. Does anyone recognise the problem described below? Does it sound like user error, a firmware bug, or a defective unit?
  
  Here's the easiest way I have to reliably recreate the problem:
  
  1) attach channel one to calibration point
  2) power up scope and adjust amplitude, timebase and trigger level to get a nice view of the square wave
  3) to make it easier to see when it stops, turn on frequency statistic and set to difference to get an incrementing count at the bottom of the screen
  4) wait a short while, the waveform will stop updating and the counter will stop after anywhere between 4 and 200 counts.
  
  When the waveform updates stop, adjusting any control that would change the waveform on the screen (horizontal position, vertical position, amplitude, timebase, etc.) starts the updates going again, but only for a short while.
  
  In case this description isn't clear, I've made a short video of the problem occurring:
  
  
  At the start of the video it's already got stuck after 38 counts, I press horizontal centre to start it again, it gets stuck at 59... 79... 175... 182... 220.
  
  As you can probably imagine this makes the scope near useless, as when I'm probing around a circuit I've now way of knowing if the scope is showing me what's on the end of the probe or whether it's stopped updating the screen.
  
  
  Thanks in advance for any suggestions, I'm hoping I can get past this problem without needing to send the scope back.
  
• #1 Reply
  Posted by flatlander on 09 Nov, 2014 04:17
• Just got my MSO2072A and noticed the same thing. I used a function generator and the scope no longer updates when the frequency and/or amplitude of the signal changes. My software/hardware details are below:
  
  Model: MSO2072A
  Software version: 00.03.01.00.04
  Hardware version: 1.1.2.2.0
  FPGA version: SPU: 04.00.09, WPU: 01.01.03, CCU: 12.29.00, MCU: 00.06, LAU: 01.01.04
  
  Must be a hardware or software issue. Fortunately it's easy to reproduce with your instructions. What are your SW/HW versions?
  
  
• #2 Reply
  Posted by esar on 09 Nov, 2014 11:35
• All of my version numbers are exactly the same as yours.
  
  It's possible that I may have fixed it, after repeatedly pressing the left F6 key during boot to clear the FRAM, the problem appears to have gone away. I'd tried this previously without any luck, but I think I held it down continuously instead of repeatedly pressing, so maybe that's made a difference this time.
  
  There is one thing remaining though that makes me worry that I haven't fixed it completely, after boot I don't get any traces on the screen, I just get the window with the option trial time remaining and no traces underneath. If the probe is not attached to anything it will have "auto" in the top left and attaching the probe to the calibration point will change that to "T'D", all with no traces on the screen. To get the traces to appear I have to twiddle one of the knobs, similar to what I had to do when the display stopped updating previously.
  
  I'll keep checking and report back if I get the steps from my first post to recreate it again.
   
• #3 Reply
  Posted by flatlander on 09 Nov, 2014 11:38
• I tried that too and it 'seemed' to have gone away for a bit but it's come back now. Maybe an issue with the software that gets the FRAM in a dodgy state?
• #4 Reply
  Posted by esar on 09 Nov, 2014 22:59
• I've had it happen again...
  
  After I reset the FRAM this morning, I've been able to use it without issue for most of the day, although I've almost exclusively been using the digital channels.
  
  Throughout the day I've been attempting to recreate the problem using the instructions in my first post, but have failed, often having the statistics counter go up into the tens of thousands of counts.
  
  This evening though, I've had it happen again. I don't yet now what steps are necessary to make it happen but I can say what I was doing at the time:
  
   * I only had channel 1 enabled
   * I had the frequency counter enabled for channel 1. Not the one I describe in my first post from the statistics at the bottom of the screen, instead the one that's enabled via the Measurement menu and appears at the top right. 
   * I had my finger on the end of the probe making it pick up lots of mains hum, but also a lot of higher frequency noise from a near by circuit I've been testing
   * I had the timebase zoomed in quite a long way looking at the higher frequency noise within the mains hum
   * I had the trigger set to Edge on channel 1 and was moving the level up and down.
  
  At some point while I was doing this the display just stopped updating and from that point on I've been able to recreate the problem using the steps in my first post.
  
  Repeatedly pressing the left side F6 during boot has successfully cleared the problem again.
  
  I need to experiment more to try and narrow down what triggers the problem.
  
• #5 Reply
  Posted by esar on 15 Nov, 2014 11:34
• I still haven't managed to find out exactly what triggers this issue, but I suspect it might have something to do with the frequency counter.
  
  While trying to track down the cause I've found another way to make it happen that simply involves enabling the frequency counter, though it seems it may be dependent on the input signal. I found this while looking at the vertical sync signal from an ADV7611 HDMI receiver IC, this is a wide pulse repeating at 50Hz but also has a lot of much higher frequency (~140MHz) noise from the switching of the 24 bit wide pixel bus.
  
  I've made another video demonstrating the issue. Here you will see the signal updating ok (if I left it it would continue to update for hours without issue), I then enable the frequency counter for channel 1 and within a few seconds the display stops updating:
  
  
  This appears to be 100% recreatable with this signal and clearing FRAM has no effect. However it doesn't happen with the calibration signal. Unfortunately I dont' have a signal generator so it's hard to try different signals to try and narrow down the root cause.
  
  As not many people seem to be having this issue I suspect this must be a defect with this particular unit. It's just too easy for me to find different ways to make this happen, so I can't see how it would ever have got past QA if it was a more general problem.
• #6 Reply
  Posted by David_AVD on 17 Nov, 2014 00:42
• I have an MSO-2072A on order (ETA is end of the month), but I'm now wondering if I should cancel it?   
  
  The immediate need I had for it has come and gone, so would I be better off waiting to see what firmware updates Rigol come out with?
• #7 Reply
  Posted by Tyrian on 17 Nov, 2014 02:20
• I've just gotten my MSO2072A set up today and ran into this issue within just a few minutes of turning it on.  I was testing my scope by connecting it to my function generator and cycling through the standard waveforms.  The first time it happened, I switched my generator to output noise (~12MHz), then flipped it to a sine wave (1kHz).  The noise was still on screen, but the frequency display in the corner did change from ~12MHz to 1kHz when I changed from noise to a sine.  Bumping the time shift knob did force the screen to update to the sine wave.
  
  My software version is 00.03.00.SP1 and my hardware version is 2.2.  How did you manage to get the extended versioning info, flatlander?  My system menu only give me those two numbers.
• #8 Reply
  Posted by flatlander on 17 Nov, 2014 02:29
• 
  
  Quote from: Tyrian on Today at 10:20:20 AM

  My software version is 00.03.00.SP1 and my hardware version is 2.2.  How did you manage to get the extended versioning info, flatlander?  My system menu only give me those two numbers.
  

  
  

  See

  https://www.eevblog.com/forum/testgear/first-impressions-and-review-of-the-rigol-ds2072-ds2000-series-dso/msg158684/#msg158684

  
  

  
  
• #9 Reply
  Posted by Tyrian on 17 Nov, 2014 02:45
• Thanks, flatlander.  Here's my extended versioning info for posterity:
  
  Software Version:  00.03.00.01.03
  Hardware Version:  1.1.2.2.0
  SPU:  04.00.07
  WPU:  01.01.03
  CCU:  12.29.00
  MCU:  00.06
  LAU:  01.01.03
  
  I'm going to take a video of this issue tomorrow too.  I bought my gear from TEquipment.net, so I'll get in touch with them and show them what's in this thread.  Maybe they'll have some insight.
• #10 Reply
  Posted by centon1 on 18 Nov, 2014 05:07
• Tyrian,
  
  I also have a MSO2072A with the same version numbers as you, which I also bought from TEquipment.net.
  
  I have the same issues as you and others are experiencing plus I can just turn it on and leave it and after about 10 minutes it will hang.
  
  A hard power reset is the only thing that brings it back only to start the cycle again.
  
  Love to hear what they have to say.  Thanks.
• #11 Reply
  Posted by esar on 18 Nov, 2014 19:16
• Quote from: centon1 on 18 Nov, 2014 05:07

  I have the same issues as you and others are experiencing plus I can just turn it on and leave it and after about 10 minutes it will hang.
  
  A hard power reset is the only thing that brings it back only to start the cycle again.
  

  
  Have you tried resetting the FRAM?
  
  During the first day of use when I got mine it locked up solid something like 6 or 7 times, but I've not had a single lock up since.
  I've no way to know if the FRAM reset is what fixed that or not, but it's certainly worth a try if you haven't already.
  
• #12 Reply
  Posted by Tyrian on 18 Nov, 2014 21:18
• Alright, I just got off the phone with TEquipment.  They gave me Rigol's number for tech support.  After talking with Jason at Rigol (who was really helpful) for about half an hour, he's going to do some checking on this issue.  One of the big things was that my version numbers indicated that my scope was manufactured around August.  Since that time there has been one firmware update for my scope.  He's going to send me an updated firmware file that I can flash on my scope later today.  I'll probably have to wait a couple of days though to actually flash it, as the weather has caused at least one brownout where I live.  I've also sent him links to both this forum thread and my video. 
  
  Hopefully, we'll know more soon, but so far it's looking promising.
• #13 Reply
  Posted by David_AVD on 18 Nov, 2014 21:58
• I've cancelled my MSO-2072A order now as I didn't want to get stuck with a scope that doesn't work properly out of the box.
• #14 Reply
  Posted by centon1 on 19 Nov, 2014 02:07
• Quote from: esar on 18 Nov, 2014 19:16

  Have you tried resetting the FRAM?
  

  
  No I hadn't but have now and it seems to be more responsive and hasn't hung after an hour. I'll keep watching it and wait to hear more about the firmware update coming to Tyrian.
  
  Thanks for everything.
• #15 Reply
  Posted by flatlander on 19 Nov, 2014 02:14
• Quote from: centon1 on Today at 10:07:34 AM

  
  I'll keep watching it and wait to hear more about the firmware update coming to Tyrian.
  

  
  
  Both esar and I have the latest firmware already (00.03.01.00.04) and still experience the display freeze issue.
• #16 Reply
  Posted by Tyrian on 19 Nov, 2014 04:46
• I have the new firmware now, but haven't flashed it yet.  I'm currently experiencing really bad weather and have had a couple of brown outs already.  I'll flash it in a couple of days once power is stable again.  In the mean time, I'm going to cobble up an auto-switching test harness with a couple of 555 timers, filter, and relay.  I'm getting a little tired of testing by manually toggling my function generator. 
• #17 Reply
  Posted by marmad on 20 Nov, 2014 17:52
• Quote from: Tyrian on 18 Nov, 2014 21:18

  I'll probably have to wait a couple of days though to actually flash it, as the weather has caused at least one brownout where I live.
  

  
  The UltraVision DSOs (1000Z, 2000, 4000, etc) have bootloader code built-in (i.e. brownout is irrelevant - just start over updating FW). No one has ever bricked one of these DSOs that I've ever heard/read about - and I don't think it's possible.
• #18 Reply
  Posted by Tyrian on 21 Nov, 2014 21:25
• I just got the new firmware flashed in and ran some tests cycling waveforms from my function generator.  Unfortunately, the bug is still present.  I'm going to mess around with it some more this weekend and try resetting the FRAM.  After that, I'll cycle some more waveforms and time how long it takes for the freeze to show up again and how long it takes to freeze successively after that.  It might be useful info to have down the road. 
  
  Also, I've updated Jason at Rigol, so hopefully we'll have another update on Monday.
  
  EDIT:  It seems we're not the only ones experiencing a screen freeze on the 2072 scopes.  There's another thread here:  https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/  Their theory is that the issue is related to the LAN portion of the scope.  Are any of your scopes plugged into a LAN?  Mine is not.
• #19 Reply
  Posted by motocoder on 22 Nov, 2014 01:58
• Quote from: Tyrian on 21 Nov, 2014 21:25

  I just got the new firmware flashed in and ran some tests cycling waveforms from my function generator.  Unfortunately, the bug is still present.  I'm going to mess around with it some more this weekend and try resetting the FRAM.  After that, I'll cycle some more waveforms and time how long it takes for the freeze to show up again and how long it takes to freeze successively after that.  It might be useful info to have down the road. 
  
  Also, I've updated Jason at Rigol, so hopefully we'll have another update on Monday.
  
  EDIT:  It seems we're not the only ones experiencing a screen freeze on the 2072 scopes.  There's another thread here:  https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/  Their theory is that the issue is related to the LAN portion of the scope.  Are any of your scopes plugged into a LAN?  Mine is not.
  

  
  That's my thread. It is not a display freeze - it is a total lock-up of the scope, i.e. does not respond to any controls. It only seems to be triggered by certain network events - still trying to determine what those are, but I suspect it's the network link dropping.
  
• #20 Reply
  Posted by Tyrian on 01 Dec, 2014 20:40
• Small update!  I heard back from Rigol late on Wednesday, and they want the scope returned to them so they can take a look at it.  I'm hoping that they'll be able to reproduce the issue and find the root cause.  If so, we might get a firmware patch that fixes the issue.   
• #21 Reply
  Posted by jlmoon on 01 Dec, 2014 21:45
• Quote from: motocoder on 22 Nov, 2014 01:58

  Quote from: Tyrian on 21 Nov, 2014 21:25

  I just got the new firmware flashed in and ran some tests cycling waveforms from my function generator.  Unfortunately, the bug is still present.  I'm going to mess around with it some more this weekend and try resetting the FRAM.  After that, I'll cycle some more waveforms and time how long it takes for the freeze to show up again and how long it takes to freeze successively after that.  It might be useful info to have down the road. 
  
  Also, I've updated Jason at Rigol, so hopefully we'll have another update on Monday.
  
  EDIT:  It seems we're not the only ones experiencing a screen freeze on the 2072 scopes.  There's another thread here:  https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/  Their theory is that the issue is related to the LAN portion of the scope.  Are any of your scopes plugged into a LAN?  Mine is not.
  

  
  That's my thread. It is not a display freeze - it is a total lock-up of the scope, i.e. does not respond to any controls. It only seems to be triggered by certain network events - still trying to determine what those are, but I suspect it's the network link dropping.
  

  
  Moto,
  
  Update on my DS2202 scope.  I put 50 ohm terms on both Ch1 and Ch2 inputs and did a self cal.  My scope has not locked up again as of yet.  I will be using the scope quite abit this evening will advise if I still have lockup on mine.
  
  JLMoon
  
• #22 Reply
  Posted by esar on 02 Dec, 2014 18:46
• Quote from: Tyrian on 01 Dec, 2014 20:40

  Small update!  I heard back from Rigol late on Wednesday, and they want the scope returned to them so they can take a look at it.  I'm hoping that they'll be able to reproduce the issue and find the root cause.  If so, we might get a firmware patch that fixes the issue.   
  

  
  Thanks for the update, I'll keep my fingers crossed for a firmware update.
  
• #23 Reply
  Posted by motocoder on 03 Dec, 2014 02:56
• Quote from: jlmoon on 01 Dec, 2014 21:45

  Quote from: motocoder on 22 Nov, 2014 01:58

  Quote from: Tyrian on 21 Nov, 2014 21:25

  I just got the new firmware flashed in and ran some tests cycling waveforms from my function generator.  Unfortunately, the bug is still present.  I'm going to mess around with it some more this weekend and try resetting the FRAM.  After that, I'll cycle some more waveforms and time how long it takes for the freeze to show up again and how long it takes to freeze successively after that.  It might be useful info to have down the road. 
  
  Also, I've updated Jason at Rigol, so hopefully we'll have another update on Monday.
  
  EDIT:  It seems we're not the only ones experiencing a screen freeze on the 2072 scopes.  There's another thread here:  https://www.eevblog.com/forum/testgear/rigol-ds2072-rma-ed-to-rigol-for-repair/  Their theory is that the issue is related to the LAN portion of the scope.  Are any of your scopes plugged into a LAN?  Mine is not.
  

  
  That's my thread. It is not a display freeze - it is a total lock-up of the scope, i.e. does not respond to any controls. It only seems to be triggered by certain network events - still trying to determine what those are, but I suspect it's the network link dropping.
  

  
  Moto,
  
  Update on my DS2202 scope.  I put 50 ohm terms on both Ch1 and Ch2 inputs and did a self cal.  My scope has not locked up again as of yet.  I will be using the scope quite abit this evening will advise if I still have lockup on mine.
  
  JLMoon
  

  
  Hi JL -
  
  My lock-up issue seems to be caused by some bug in the network parts of the DS2072 firmware. By process of elimination, I was able to determine it was being triggered by some printer/scanner software on my desktop computer. This software was spamming the network with various UDP packets to the broadcast address, as well as unicast UDP packets to the scope (the printer, since removed, had a static IP address that happened to be the same IP that the scope was on). I uninstalled the software and the lock-ups stopped.
  
  However, the story is not over. When Rigol sent my scope back, it had some beta firmware on it. This firmware occasionally locks up, regardless of whether the scope is on the network or not. However, the lock-up rate is much lower, and I suspect this issue will go away with the next non-beta release.
  
  Bottom line, I've lost what little confidence I had in Rigol's ability to ship a quality product. Hopefully they will get better at this over time. In the meantime, I am enjoying my Agilent scope, which has none of these issues
  
  Regards,
  motocoder