Agilent DSO1012A became different model after upgrade-help needed

[tibean256]

Hello all.

I am (was) an happy owner of an Agilent DSO1012A (2 channels, 100Mhz BW) and I had the stupid idea of upgrading my scope firmware after the warranty period. I say stupid because my scope was already in the last version (04.06) and when I had a look on the Agilent’s site I misunderstand that a new release had been release. In reality, I reinstalled the same 04.06 version, but the problem appeared after the upgrade (which went smoothly):
Once I restarted the scope and checked the Info window I realized my scope stayed at the same version but it lost the serial number and even worse, it became a DSO1004A (4 channels 60 MHz)!
I’ve contacted the Agilent representative for my country and they replied saying that the only way the scope can get this state is by suffering a power failure during the firmware upgrade process.  But this was not the situation as I was watching the equipment during all the process!
And the repair: about half the price it cost me!
From the web I didn’t find any reports of this situation, so I’m a bit alone with my problem…
After some investigation on the net I realized that RIGOL and AGILENT share (almost) the same firmware, and I also found Daves Jones turning a DS1052E to a 100Mhz scope with just 2 commands (changing the model and serial number). So I decided to try the same commands on my scope.
Because my scope hasn’t a serial port, I installed Agilent IO Libraries Suite as described in Programmer's Guide, and connected my scope to my PC via a USB cable. I’m able to send commands to my scope, namely “*IDN?”, and to receive the reply, but the important commands that I pretend (MODEL and SERIAL) does not provide any changes after the restart…
I also performed a downgrade to 04.03 and tried the same commands, but no luck.
I would like to try with 04.02 (the very first firmware for 1000 family), but I’m not able to find it on the net. Does anyone has got this version? I would be highly thankful!
I even opened the scope and tried to find a serial port, but only found small contacts near a uController and I’m not sure if it helps…
Does anyone had the same problem or have any suggestion?
Thanks a lot just for reading!


Regards,
T.

[Rigby]

Ouch.  Hope you figure out a fix. The fix will involve a JTAG adapter, I'm sure.

[tautech]

WTF. Really, you can't install the same version firmware without trashing the scope. You poor bugger. Scream long and hard and they might rescue you for good publicity.

[Mark_O]

I had the stupid idea of upgrading my scope firmware after the warranty period. I say stupid because my scope was already in the last version (04.06) and when I had a look on the Agilent’s site I misunderstand that a new release had been release.

I'm surprised you'd make that mistake, since the last update was almost 4 years ago.  Taking all the time to obtain it, download it, set it up on a memory stick, and reflash your scope... without ever taking a few seconds to look at the version, seems odd.

I’ve contacted the Agilent representative for my country and they replied saying that the only way the scope can get this state is by suffering a power failure during the firmware upgrade process.

Your "Agilent representative" may be confused.  1000-series Agilents were manufactured for them by Rigol (that's why the firmware files have a .RGL extension).  The Rigol units in those days (2009) lacked a separate bootloader from the app code, and I suspect these do as well.  So if there had been a power failure during the upgrade, you wouldn't have a working scope now, with wrong specs.  You'd have a brick.

Also, the ID information that you're describing isn't even located in a memory space that is affected by a firmware upgrade.  So your "rep" is doubly confused.

After some investigation on the net I realized that RIGOL and AGILENT share (almost) the same firmware, and I also found Daves Jones turning a DS1052E to a 100Mhz scope with just 2 commands (changing the model and serial number). So I decided to try the same commands on my scope.

Because my scope hasn’t a serial port, I installed Agilent IO Libraries Suite as described in Programmer's Guide, and connected my scope to my PC via a USB cable. I’m able to send commands to my scope, namely “*IDN?”, and to receive the reply, but the important commands that I pretend (MODEL and SERIAL) does not provide any changes after the restart…

You should try the query versions of the commands first, to confirm they work.  They're not documented, but they are in the 4.06 firmware.  Then after issuing the setting versions, send a :SYST:ERR? query.  You may have to send several, because there's a queue, and you get only one back on each query.  You'll likely find a 67,"Not executable" or something to that effect.  It's also entirely possible that you can change the Model and Serial, for one power cycle, but not be able to force them out to NV memory.  Just speculating on that.

I also performed a downgrade to 04.03 and tried the same commands, but no luck.
I would like to try with 04.02 (the very first firmware for 1000 family), but I’m not able to find it on the net. Does anyone has got this version? I would be highly thankful!
I even opened the scope and tried to find a serial port, but only found small contacts near a uController and I’m not sure if it helps…

Looking for a serial port isn't of any use to you at all.  You're already talking to the scope via USB.  A serial link isn't magic, and won't do anything you can't already do over USB.

As someone here already stated, a JTAG link (and special software/knowledge of where this data is stored) is likely required at this stage to restore your SN and Model number.  How you actually hosed it is still questionable in my mind.  It seems rather unlikely it could happen during a normal reflash, without anyone ever having experienced (and reported) it before.

[plesa]

Send the request to official Agilent support in US. Give them the serial number and problem description. I hope they will find the solution for you.
I have a really good experience with their service. The local distributors are good for selling equipment not for such a kind of support.

[Mark_O]

"Ouch.  Hope you figure out a fix."

"WTF... You poor bugger. Scream long and hard and they might rescue you for good publicity."

"oh dear   This is putting me right off agilent, they should NOT be treating people like this..."

"Updates should always be free ...  It would be great for competition to see this on a YouTube channel."


Interesting.  Before we all grab our torches and pitchforks, and storm Agilent HQ, it might be wise to keep in mind this is a report from a member with one post, who's been here for 10 days.

I'm not saying he isn't completely on the up & up, and I do sympathize with his situation if so.  But the situation he's described isn't the only scenario that could have gone down.

For instance, speaking only hypothetically, someone could have read about all the hacks that have been done to Rigol scopes, and in particular the BW upgrade on their 1000-series, years ago.  Realizing that the Agilent scope they had was made by Rigol, and possibly had a lot of firmware aspects in common, one might be tempted to do a bit of experimenting to see what was possible (200 MHz, maybe?).

Now, even on the Rigol's, you had to be very careful when sending these commands into the unit, because they were implemented so poorly.  I.e., no error checking.  So if you make a mistake, you can't correct it.  This was even worse over serial than USB, because folks would try and backspace to correct typing errors... only that didn't actually erase anything!  And the end results?  Munged Model and SN strings in their scopes.  Even typing too many characters could screw them up, big time, because there was no bounds checking. 

Who knows what might happen on the Agilent's?  The commands are there, because I just looked at the binary.  So one goes looking for older versions of the firmware, which might function differently, and allow one to recover.  Possibly not, but what do you have to lose?


As I said, I'm NOT stating that's what actually happened.  But it seems like a more plausible scenario to explain the current situation.  And once someone had gotten themselves into that uncomfortable position, it would be logical that they'd like to have the scope vendor bail them out, for free.

[tautech]

Yes Mark that is what "MIGHT have happened.
However another assumption is that without the Manufacturer or their agents support the OP has turned to this forum for the assistance he can get nowhere else. Call me naive but I can only take him at face value.

But you are right to question his situation, it is not the first time the forum has seen this type of thing.

[tibean256]

Hi.

First of all thanks for your replies, even if they do not contain any useful info in order to solve my problem. That means at least you are interested in not getting to the same situation as I did.
As stated by Mark, yes, this was my first post (in a blog!) and i'm here (registered) just for 10 days, although I’m visiting the site for a long time. To be honest, I'm not use to blogs and creating an account at EEVblog just to ask for help on this problem was my scream of desperation…
But what I described was what happened. And just that. I even thought that maybe I could being using another firmware from other version (DSO1000B) because the downloaded file name is always the same, but after a lot of checking I discarded that situation.
The firmware upgrade process should be a very clean process, at least in my opinion, and I was quite comfortable when I did not performed a close check regarding the version because I knew (or I thought) it would not harm my scope even I use a different version. At least I was expecting that from official Agilent releases.
I will try the commands once more with Mark’s recommendation (SYST:ERR?) and see what I get.

Thanks again,
T

[Mark_O]

However another assumption is that without the Manufacturer or their agents support the OP has turned to this forum for the assistance he can get nowhere else. Call me naive but I can only take him at face value.

Yes, sorry to not be more clear.  I think we should provide whatever help we can (hence my suggestions on the :SYST:ERR? command, etc.), while at the same time not getting too much up in arms about one local Agilent rep's lack of assistance.  (which seemed to be the path the wagon was taking.)

I think plesa's advice would be well worth the OP following up on.

[Rigby]

I'm trying to imagine the shock you're going to feel when I tell you that HP is about to start charging business customers for firmware upgrades for business laptops, desktops, workstations, and servers.

[Mark_O]

"Updates should always be free ...  It would be great for competition to see this on a YouTube channel."[/i]
As I said, I'm NOT stating that's what actually happened.  But it seems like a more plausible scenario to explain the current situation.  And once someone had gotten themselves into that uncomfortable position, it would be logical that they'd like to have the scope vendor bail them out, for free.

This sounds very biased pro a DSO vendor -

Does it?  Someone raises a note of caution, and suggests that flame-broiling a manufacturer may not yet be justified, and that's biased?  To me, it just seems reasonable.  I never claimed that things didn't happen exactly as the OP described.  However it was definitely a strange occurrence, and hard to explain (for many reasons) from existing experience.  OTOH, there is a simple alternative explanation that's not only totally plausible, but has actually happened numerous times.  I pointed it out, because some may not remember that far back.

If I'm biased at all, I think it's towards logical reasoning. 

...are you by accident affiliated with a DSO vendor or one of its sales channels?

No.

In period 2010 - 2011 I ran twice in situation where an american DSO manufacturer was sourcing DSOs from an ODM in Asia, with large profits.
The first DSO was ordered and shipped with firmware - where it was not possible to trigger correctly an event - we had many mails with chief of sales, it came clear that they did not have the ODM software under control, we had a discussion at Elektronica 2010 on their booth - they would contact us again, never heard from them and it did not surprise us that they were sold ... - One person that made many claims for this on EEVBLOG was refunded and many others were left aside ...

Yes, I've had bad experiences myself.  I've even shared some of them here.  One involved broken promises from Rigol tech support to provide updated firmware for their 1000C/CD series, which never materialized.  Once the 1000E/D appeared, Rigol lost all interest in supporting their previous models.  So I feel the pain.

Sometimes YouTube and EEVBLOG are the only Outlets to ventilate our DSO customer satisfaction ...

Nothing wrong with ventilation.  However, everyone piling on and condemning a manufacturer, before even reaching out and exploring more proactive solutions, isn't the most effective strategy.  IMO.  YMMV.

Yes - Updates for firmware to fix bugs should always be free.

I never stated, nor suggested, otherwise.     I'm in 100% agreement.  Perhaps you were confused by my inclusion of that quote in my list?  However, the problem here isn't about getting an update, free or otherwise.  (Which is what I was trying to point out.)  It's about fixing a device that's been compromised.  If that happened through no fault of the user, then it should be repaired at no charge, of course.  The OP needs to open a dialog with someone farther up the chain at Agilent than his local rep.

[Mark_O]

So, Tibean, how are things going with Agilent support?  Any luck with that yet?

In the meantime, did you confirm that the MODEL? and SERIAL? queries are working?  Did you then try the setting versions, and check the error status afterwards?

Did you then test to see (without power-cycling) if the model and serial # were showing up properly?  If so, you may then be able to at least use your scope at it's proper bandwidth, until you get a permanent fix.  Having to send a command each time you power up is a PITA, but better than being stuck at 60 MHz.  Or does that not work?

[Mark_O]

Here's some US contact info for you, if you haven't found it yet.  You didn't say where you're located, so there may be a better option closer to you.  I got all this info when I downloaded the 4.06 firmware a few days ago.  When I got my confirmation email...

"Thank you for downloading: 1000 Series Oscilloscopes Firmware (Version 011.04.00.04.06).
If you had any problems with the download you can contact us."


toll-free    1 800 829-4444 Press #, then 2
fax           1 800 829-4433
hours       8:00am - 8:00pm ET, Mon - Fri
address    P.O. Box 4026
                Englewood, CO 80155-4026  USA

[tibean256]

Hi Mark.

Thanks for your reply.
I have tried the commands, but no luck. The MODEL seems not to be a defined header, and SERIAL seems to be accepted, but does not changes the SN...

Here's a resume of the commands I sent. For each "Send Command" or "Send & Read", I sent also the SYST:ERR?.
I omitted my SN.

Send & Read:

-> *IDN?
<- Agilent Technologies,DSO1004A,DSO10000000,00.04.06
-> SYST:ERR?
<- 0,"No error"


Send & Read:

-> :INFO:SERIAL?
<- DSO10000000
-> SYST:ERR?
<- 0,"No error"

Send & Read:

-> :INFO:MODEL?
 ! VI_ERROR_TMO: A timeout occurred
Visa ErrorCode: 0xBFFF0015 (-1073807339)
-> SYST:ERR?
<- -113,"Undefined header; keyword cannot be found"
-> SYST:ERR?
<- 0,"No error"

Send & Read:

-> :INFO:SERIAL CNxxxxxxxx
 ! VI_ERROR_TMO: A timeout occurred
Visa ErrorCode: 0xBFFF0015 (-1073807339)
-> SYST:ERR?
<- 0,"No error"
-> SYST:ERR?
<- 0,"No error"

Send Command:

-> :INFO:SERIAL CNxxxxxxxx
-> SYST:ERR?
<- 0,"No error"

Send & Read:
-> *IDN?
<- Agilent Technologies,DSO1004A,DSO10000000,00.04.06

The behaviour is the same in 4.06 and in 4.04. I would like to try with 4.02, but i'm unable to find it on the web...

I will try US support despite being in Europe (Portugal). Maybe they are more willing to help than the local support that I have in my country which only asks for money...

Thanks and regards,
T

[Mark_O]

Hi Mark.

Thanks for your reply.
I have tried the commands, but no luck. The MODEL seems not to be a defined header, and SERIAL seems to be accepted, but does not changes the SN...

I'm sorry to hear you weren't more successful.  And yes, if it won't respond to a MODEL query, there's not much chance it would handle the setting mode. 

I hope you get a better response with Agilent corporate, than you got from your local office.  I suspect you will.  Heck, tell the rep in Portugal that you want your other two channels!     I.e., the Model reported is DSO1004A, which is not just a 60 MHz version, but also 4 channels.  I missed that the first time.

As Rigby mentioned some time back, this will likely require a JTAG fix, which means shipping it off and waiting.  But honestly, I'd be a bit concerned even getting it back fully operational again.  Why?  Because if some day Agilent ever does release new firmware, it wouldn't be shocking if loading it also corrupted memory areas that are not supposed to be touched during a reflash.  So MODEL and SERIAL would be gone again.  On a properly functioning unit, this should never happen.  Which suggests there is a hardware defect of some sort, which could cause the same thing to happen again.

The other thing I'd be concerned about is what other areas in your non-volatile memory have been affected, beyond the two you can obviously see?  I.e., there are two Cal regions in memory.  One that the user can adjust by running the Cal procedure, but the other area is only settable in the Factory.  If either of those areas were impacted, you could see worse operational anomalies than just a reduction in bandwidth.

When you contact Agilent, make sure you make them aware of both concerns.  If this was the first time you have ever reflashed your DSO1012A, I'd be sure and point that out to them as well.

Good luck!