Agilent MSO 5000/6000/7000 - anyone hacked these scopes?

[mikeselectricstuff]

That sample rate hack doesn't improve bandwidth
Attatched pics show a 250-750MHz stepped sweep before & after - no difference.

Sample rate on digital channels appears to still be 2Gs/s

My (early s/n 440013xx MSO6034A) didn't seem to work with the soft-loading method - appeared to go through the normal process of sitting a while with the "Single" LED on, but instead of booting the new FW it just sits there lighting up lines of the front panel LEDs til you pull the USB stick, at which point it reboots.

Hacked FW loads to flash OK though - it was only after loading I suddenly thought that without the soft-load capability, how would I recover if it hung, but I think that "emergency" update file is what that is for. I did try loading that version but again it sat in a led-flashy loop.
Think I'll stay away from playing with that scope - I still have a more recent MSO6012A to play on.
I wonder if the sample rate  hack will improve sample rate on digital channels on that...?

[Carrington]

That sample rate hack doesn't improve bandwidth
Attatched pics show a 250-750MHz stepped sweep before & after - no difference.

I feared that, thanks for check it. This afternoon I will try to dumping all the internal memory, to investigate this.
For now I have the bootloader.

My (early s/n 440013xx MSO6034A) didn't seem to work with the soft-loading method - appeared to go through the normal process of sitting a while with the "Single" LED on, but instead of booting the new FW it just sits there lighting up lines of the front panel LEDs til you pull the USB stick, at which point it reboots.

Hacked FW loads to flash OK though - it was only after loading I suddenly thought that without the soft-load capability, how would I recover if it hung, but I think that "emergency" update file is what that is for. I did try loading that version but again it sat in a led-flashy loop.
Think I'll stay away from playing with that scope - I still have a more recent MSO6012A to play on.

I don't think that I can do anything about it. 
Maybe it can be permanent "modified" using a command from VxWoks console.

When I get time I'll see if the digital channels are improved.
I wonder if the sample rate  hack will improve sample rate on digital channels on that...?

No, this improvement is only for 1GHz models [MSO610*A MSO710*A].

[dfnr2]

My (early s/n 440013xx MSO6034A) didn't seem to work with the soft-loading method - appeared to go through the normal process of sitting a while with the "Single" LED on, but instead of booting the new FW it just sits there lighting up lines of the front panel LEDs til you pull the USB stick, at which point it reboots.

Interesting.  Does it do that with the original sys6000.jzp, or only the hacked one?
Did you make certain the header was saved to a temp file on unzp and restored from that file on packjzp?  The header looks like:

@(#)REV: 06.16.0001 Apr 27 2011 15:25:28

And you should see it at the beginning of the hacked .jzp file if done properly.

Is it just the USB boot that fails, or does it not load via the file explorer "load file" mechanism?

By loading to flash, do you mean logging in via VxWorks and copying the file from USB to C:/bin?  It seems odd that the .jzp would load from the C:/bin directory, but not from usb.

I wonder if there is a Vxworks difference.  In my vxworks shell (in C mode,) version() yields:

-> version()
VxWorks (for Agilent KOM PPC405, SA27E rev1) version 6.4.
Kernel: WIND version 2.10.
Made on Apr 27 2011, 15:25:40.
Boot line:
tffs;usb(0,0):sys7000A f=0x8 tn=a-m7104a-040060 o=emac0
value = 67 = 0x43 = 'C'

What do you get from your version() call?

[abyrvalg]

Looks like a plain uncompressed .bin is required for some older 6ks (see 6k emergency procedure description - it says put BOTH bin and jzp to USB stick).

[mikeselectricstuff]

Looks like a plain uncompressed .bin is required for some older 6ks (see 6k emergency procedure description - it says put BOTH bin and jzp to USB stick).

Possibly - boot version is 01.10 BTW

[dfnr2]

Is it just the USB emergency boot that won't use the .jzp?

[abyrvalg]

Thanks to Carrington's enthusiasm we had identified the real source of BW/channels/MSO capabilities bits: they are read from Xilinx FPGA (internal name "Nevada", graphics controller) register. The availability of this value prior to any serious hw init suggests something simple like strapping resistors. So we ask everybody interested in this "project": please share hi res pictures of board area around FPGA. A 32-bit value at address 0xF6000004 (that is capabilities reg) is also interesting.

This value doesn't come from different FPGA bitstreams, the bitstream is same for entire family: it is in gspXXXX.jzp file.

[mikeselectricstuff]

Thanks to Carrington's enthusiasm we had identified the real source of BW/channels/MSO capabilities bits: they are read from Xilinx FPGA (internal name "Nevada", graphics controller) register. The availability of this value prior to any serious hw init suggests something simple like strapping resistors. So we ask everybody interested in this "project": please share hi res pictures of board area around FPGA. A 32-bit value at address 0xF6000004 (that is capabilities reg) is also interesting.

This value doesn't come from different FPGA bitstreams, the bitstream is same for entire family: it is in gspXXXX.jzp file.

Interesting - there is a Xilinx flash config PROM - presumably the stream in that file is to reprogram the flash.
Here is a pic of the MSO6012A, Resistor at bottom-left corner looks a lot like a pullup/pulldown option

[Carrington]

A 32-bit value at address 0xF6000004 (that is capabilities reg) is also interesting.

This value can be get with this command from vxWorks console (cmd mode):
mem dump -n 1 -w 8 0xF6000004

[Carrington]

Interesting - there is a Xilinx flash config PROM - presumably the stream in that file is to reprogram the flash.
Here is a pic of the MSO6012A, Resistor at bottom-left corner looks a lot like a pullup/pulldown option

Thanks for the picture.

From your MSO6034A video:

[mikeselectricstuff]

Just did some probing - though it looks like the resistor nearest the FPGA is an option, alternating with the empty pads to the left of it, measurements seem contradict this. (Unless it reads the pin and then outputs a low - not sure why you'd do that unless  it's doubling as a debug output.

Will compare to my mso6034a later before investigating further

Another possibility - I wonder if maybe the FPGA prom has a default config, but then gets reloaded once the system boots. Probably wouldn't be too hard to check by probing (with another scope of course!)

[Carrington]

Just did some probing - though it looks like the resistor nearest the FPGA is an option, alternating with the empty pads to the left of it, measurements seem contradict this. (Unless it reads the pin and then outputs a low - not sure why you'd do that unless  it's doubling as a debug output.

Will compare to my mso6034a later before investigating further

Another possibility - I wonder if maybe the FPGA prom has a default config, but then gets reloaded once the system boots. Probably wouldn't be too hard to check by probing (with another scope of course!)

I dont know but I think worth trying.


If all this fails, we still have a patch for MSO6034A that allows 1ns/div and 4GSPS, but unfortunately the BW remains at 300MHz.

[Carrington]

Just as a curiosity, to enable the service menu (only for 6000 series) type this in the vxWorks console:
   mem modify -w 1 0x00966E67
vxWorks response should be:
   0x00966e67:    0x00-
Now type "0x01" after "0x00-" to enable service menu.
new vxWorks response should be:
   0x00966e68:    0x00-
Now type "." after "0x00-" to exit.

Now go to "Options" -> "Licenses".


Note: To enable service menu in the 7000 series use this command:
mem modify -w 1 0x009A2187

[abyrvalg]

The bitstream is reprogrammed during update only, no load at each start. If the scope finds gsp file present in c:/bin at start, it programs it into PROM (there is a GPIO bitbang JTAG XSVF player), then deletes.

The BW bitfield of caps reg is 4 bits wide with possible values 1,2,4,8.

Other bitfields:
2 bits defining number of channels with possible values 1-2CH, 2-4CH
5 bits defining MSO capability and some yet unknown caps with possible values 0,1,2,4,8,16, 1 means "no MSO", rest are MSOs with some additional options, 16 defines some cool model with external serial keyboard instead of normal panel buttons.

It's unclear how FPGA itself samples those resistors - there can be something more than 0/1, like floating state detection, also possible values sets suggest "something to one-hot" decoding  (it would look silly to sacrifice so many IO pins for direct one-hot strapping), so it's time for hw test.

[abyrvalg]

Carrington, try setting "service mode" combined with something like "all lics" in that service menu. There are some functions that adds such command line parameters, and almost all of them require "srv" param to be present too.

[Carrington]

Carrington, try setting "service mode" combined with something like "all lics" in that service menu. There are some functions that adds such command line parameters, and almost all of them require "srv" param to be present too.

Yes, a lots of demo modes (Update rate, MSO, Serial Buses, Data Bursts and Mask Test).

[mikeselectricstuff]

16 defines some cool model with external serial keyboard instead of normal panel buttons.

I can't immediately find details but they did announce a "headless" version of this scope for ATE etc., which was the mainboard in a rackmount case with no keyboard or display.
Not sure if it ever actually appeared, but chances are there could be some support for it

[Carrington]

16 defines some cool model with external serial keyboard instead of normal panel buttons.

I can't immediately find details but they did announce a "headless" version of this scope for ATE etc., which was the mainboard in a rackmount case with no keyboard or display.
Not sure if it ever actually appeared, but chances are there could be some support for it

The L versions maybe (DSO/MSO6***L)?

[abyrvalg]

Yes, a lot of demo modes (updatr rate, MSO, serial bus table, ...).

Oops, I didn't finished my thought: try setting service mode with some lic feature checkboxes (service mode checkbox must be set, not just that flag in memory) then reboot - it should persist, if I understood that part correctly.

[Carrington]

Yes, a lot of demo modes (updatr rate, MSO, serial bus table, ...).

Oops, I didn't finished my thought: try setting service mode with some lic feature, then reboot - it should persist, if I understood that part correctly.

Yes, all remain.

[abyrvalg]

Good! So it's unnessesary to keep patched sys to have features enabled.

[Carrington]

Good! So it's unnessesary to keep patched sys to have features enabled.

But if the service mode is disabled some of this options disappear.
But this is not a problem, we just have to leaving active the service menu.
However, I prefer the patch, with non-default options: CIR, 1MV, ...

[mikeselectricstuff]

Good! So it's unnessesary to keep patched sys to have features enabled.

But if the service mode is disabled some of this options disappear.
But this is not a problem, we just have to leaving active the service menu.
However, I prefer the patch, with non-default options: CIR, 1MV, ...

Do we know what 1MV actually does?

[Carrington]

Do we know what 1MV actually does?

Yes, it is a magnification of 5mV/div, no real range.

[Carrington]

I have a MSO6034A for a week now, is 7 years old, but a internal file indicate that was calibrated by TestEquity half a year ago.
Is necessary a special equipment to calibrate it or not?