Rigol DS10xxZ firmware re-write

[cBaer]

I did some research.
According to Dave the ADC in these Scopes is a HMCAD1511.
Datasheet:
http://www.analog.com/media/en/technical-documentation/data-sheets/hmcad1511.pdf

Since i think we have to write a new FPGA Frimware image i searched for HDL Code for that chip.
And found it for the EVAL-Board here:
https://ez.analog.com/thread/51904

The EVAL-Kit uses a Spartan 6 too.

By the way im looking to buy one of these scopes so i can do more for this project, so does anybody know where i can get one (can be a used/defect one to some extend).

[tmbinc]

The frontpanel (both buttons and LEDs) are connected to the UART (AUART0 if i remember correctly); it runs at 1MBit/s.

To set the LEDs, you have to send one byte; the upper nibble indicates which LEDs to update, the lower nibble is a bitmask. So, "33" for example would enable SINGLE and REF, but disable MATH and the red RUN/STOP led, and leave the other LEDs alone.

Code: [Select]

1x 1 rot. button
2 CH1
4 CH2
8 CH3
2x 1 CH4
2 LA
4 SOURCE
8 RUN/STOP green
3x 1 SINGLE
2 REF
4 MATH
8 RUN/STOP red
4x 1 trigger single
2 trigger normal
4 trigger auto

The button presses are little bit complicated, any pressed button generates a packet starting with "AA", then 9 bytes, and then something that appears to be a checksum. I guess with just a little bit of observation it can be figured out.

[hexreader]

The frontpanel (both buttons and LEDs) are connected to the UART (AUART0 if i remember correctly); it runs at 1MBit/s.

To set the LEDs, you have to send one byte; the upper nibble indicates which LEDs to update, the lower nibble is a bitmask. So, "33" for example would enable SINGLE and REF, but disable MATH and the red RUN/STOP led, and leave the other LEDs alone.

Code: [Select]

1x 1 rot. button
2 CH1
4 CH2
8 CH3
2x 1 CH4
2 LA
4 SOURCE
8 RUN/STOP green
3x 1 SINGLE
2 REF
4 MATH
8 RUN/STOP red
4x 1 trigger single
2 trigger normal
4 trigger auto

The button presses are little bit complicated, any pressed button generates a packet starting with "AA", then 9 bytes, and then something that appears to be a checksum. I guess with just a little bit of observation it can be figured out.

Thanks, that motivates me to decode further. Might take a while, but I will publish the results...

By the way, curious, how did you work that out please?

[tmbinc]

By the way, curious, how did you work that out please?

I simply observed serial port communication and correlated that with blinking LEDs .

Later (from Linux) i've systematically tried all combinations.

[hexreader]

Keyboard A 20 pin connector assuming pin 1 at the top:

1 gnd
2 gnd
3 ?
4 ?
5 ?
6 ?
7 gnd
8 ? (scope shows 24MHz clock at all times at approx 0 to 3V)
9 gnd
10 11 12   3.3V
13 Row 1
14 Row 2
15 Col 5
16 gnd
17 Col 4
18 Col 3
19 Col 2
20 Col 1
The five connections marked ? are resistor-terminated and seem to run to a bus that includes mainboard FPGA (with heatsink) and Cyclone chip to it's right

PSU Connections:
BRN 50Hz (AC_Trig)
ORG Gnd (Fan -)
White 9.0V (Fan)
Red 5.0V (5V5A)
Red 5.0V (5V5A)
Blk Gnd
Blk Gnd
Yel 7.5V (6.3V)
Yel 7.5V (6.3V)
Blk Gnd
Blue 17.5V
Grey -17.5V
Blk Gnd
Grn -7.5V

Picture of PSU main chip attached

[hexreader]

By the way, curious, how did you work that out please?

I simply observed serial port communication and correlated that with blinking LEDs .

Later (from Linux) i've systematically tried all combinations.

Sorry to keep bugging you, but I have not managed to find serial communication signals for keyboard and LEDs. Where can I put scope probe(s) to see the signals each way please?

I am slowly getting to grips with how the scope works, but struggling.

[Ink]

I have reversed engineering the front end of my DS1000Z too,but not sure if it's right,not confirm yet.Actually,I thought about the same open source scope before,but I know noting about FPGA and Linux,so I give up. :palm:hope you can keep going.If there are anything about analog front end I can help,please let me know.

[hexreader]

I have reversed engineering the front end of my DS1000Z too,but not sure if it's right,not confirm yet.Actually,I thought about the same open source scope before,but I know noting about FPGA and Linux,so I give up. :palm:hope you can keep going.If there are anything about analog front end I can help,please let me know.

Wow! that is seriously impressive

Where did you get component numbering from?  (U2A, Q4 etc) . My scope mainboard has no component numbers. Did you make them up? or did you have a way to know Rogol numbering. Either way, your schematic will become the standard that the rest of us will follow.

Many thanks for posting - maybe there is hope for this project after all....

[Ink]

I have reversed engineering the front end of my DS1000Z too,but not sure if it's right,not confirm yet.Actually,I thought about the same open source scope before,but I know noting about FPGA and Linux,so I give up. :palm:hope you can keep going.If there are anything about analog front end I can help,please let me know.

Wow! that is seriously impressive

Where did you get component numbering from?  (U2A, Q4 etc) . My scope mainboard has no component numbers. Did you make them up? or did you have a way to know Rogol numbering. Either way, your schematic will become the standard that the rest of us will follow.

Many thanks for posting - maybe there is hope for this project after all....

just ignore the component number,I made them up.

[hexreader]

just ignore the component number,I made them up.

On the contrary; those component numbers will now become the standard. Somebody had to assign a numbering system, and it seems you are the first.

Now needs somebody to invent numbers for the remaining components on the mainboard. I would annotate Dave's pictures with component numbers, but with only 1MB limit on pictures, it is more trouble than I can live with

[bitseeker]

An alternative to annotating high-resolution photos is to make a component list and corresponding component-finder as is done in many service manuals. The component-finder image would be a line drawing with all the component labels, which should be a much smaller file than a photo.

Of course, one could just put large images elsewhere, such as on xDevs, where all the project details can be tracked and documented.

[rhb]

FWIW

In 2004 David Donoho of Stanford introduced the concept of compressive sensing.  There is a 2014 PhD dissertation on a compressive sampling oscilloscope.  The dissertation is:

https://smartech.gatech.edu/bitstream/handle/1853/.../TZOU-DISSERTATION-2014.pdf

To do this you need to be able to trigger sampling at random times.  The granularity of the clock determines the bandwidth of sampling.  Typically about 5x increase in BW per sample is achievable, though it takes significant compute, so not for real time yet.  But the really cool part is that the random sampling times eliminate aliasing without the expense of an anti-aliasing filter. So a scope that implements compressive sampling is limited only by the BW of the analog front end.

The deep buffer on the DS1000Z series makes this especially attractive.  Compressive sensing would make it 5x deeper.

I'm interested in ANY low cost  scope that will allow me to treat the ADC channels as one would those on an MCU.  But I've got a DS1102E, so Rigol is a natural path to start down.  If someone works out how to trigger a single sample after a user specified delay. I'd *really* like to know.

[cBaer]

Did anybody start with the FPGA part yet?

[affinekinetic]

@hexreader, how did you get the lighting such that the chip identifiers are readable?

Very delayed reply, and apols for off-topic, but https://xdevs.com/guide/hwphoto/ is the best guide I've seen for getting high-quality circuit board or component shots.

tl;dr, tripod, slow exposure (10s), dark room, wave a torch around the board from all sides to get rid of reflections & shadows.

[ebclr]

Link did work for me

This one works

https://smartech.gatech.edu/bitstream/handle/1853/51876/TZOU-DISSERTATION-2014.pdf

[hexreader]

Thread seems to have died

I have been working in the background learning about FPGAs, but am afraid to connect either of my FPGA programmers to Rigol Scope.

Is there any kind person out there who can tell me how to reliably read FPGA information out of the configuration Flash chips for main Xilinx Spartan chip and Altera Cyclone 2 please.

I will be much happier experimenting on FPGAs on DS1054Z when I am confident that I have a "plan B" for restoring scope to working condition.

I bought these two JTAG programmers for the job:    http://store.digilentinc.com/jtag-hs3-programming-cable/
[url=http://hobbycomponents.com/featured/273-altera-fpga-cpld-usb-programmer-usb-blaster-compatible?search_query=fpga&results=2]

[url=http://hobbycomponents.com/featured/273-altera-fpga-cpld-usb-programmer-usb-blaster-compatible?search_query=fpga&results=2]http://hobbycomponents.com/featured/273-altera-fpga-cpld-usb-programmer-usb-blaster-compatible?search_query=fpga&results=2[/url][/url]

I also bought logi-pi2 and some cheap Altera FPGA boards to experiment on.

My suspicion is that connecting JTAG to scope FPGAs will result in dead scope until I know how recover from bricked FPGAs

Any advice or help much appreciated. I have not given up on this project yet, but live in fear of trashing my DS1054Z.

[stj]

just reading this thread,
before you do the big firmware project, it may be handy if you created a small diagnostic program to check scopes for hardware issues.
just a thought. 

[Cerebus]

just reading this thread,
before you do the big firmware project, it may be handy if you created a small diagnostic program to check scopes for hardware issues.
just a thought. 

That's actually a damn fine idea. Part of the very nature of a diagnostic program is that you absolutely must understand the hardware you're driving to get the correct results. Thus writing a diagnostic program is a good way of proving to yourself that your reverse engineering is correct.

Further, reverse engineering often requires quite a lot of trivial test programs to see if a given feature works the way you think it does. Each of those little test programs look a whole lot like the individual tests that go to make up a diagnostic. So a deliberately written diagnostic is going to make a top-notch framework for all those little test routine that will need writing anyway - might as well make them useful in the future and keep them tidily in one place.

[Fungus]

Is there any kind person out there who can tell me how to reliably read FPGA information out of the configuration Flash chips for main Xilinx Spartan chip and Altera Cyclone 2 please.

You could try soldering wires to the chip and driving it directly but it may not work, depending on what else is connected to the PCB traces.

You could sniff the bus at startup using a logic analyzer.

The only way to be sure is to desolder the chip, read the contents, put it back again. It's a few minutes work if you've got the equipment, a big hassle if you haven't.

[hexreader]

Thanks Fungus 

Option 3 is out of the question. I have neither the equipment or the skill for SMD de-soldering.

I will go for option 2 - that looks safest. Will practice on dev boards first to prove the principles.

If option 2 does not work, then I will go for option 1.

Much appreciated...

[ali_asadzadeh]

I can boot Linux, which means we have:
USB
LCD/Framebuffer
Ethernet
Frontpanel LEDs
Frontpanel buttons

Thanks tmbinc for sharing the project, I'm an experienced Embedded coder with more than 10 years experience, maybe I could help with developing some drivers for you. But I'm not a linux guy, and in all those years I just wanted to know how to build linux and add custom device drivers to it, do you recommend any path?

[ali_asadzadeh]

But I have a Guinea pig ^w^w 1074Z-S. If it can be of any help just let me know :-)

GeorgeOfTheJungle Please send it to me, I will promise you to slay him and used it for the good of the public

[ali_asadzadeh]

What questions me is that the Spartan 6 has a maximum Speed in the ballpark of 400MHz (if you use a very very veeeeeeeeerrrryyyyyy quick HDL) but it is specified at 1GSa/s. So how did they implement that?

cBaer, please note that,It has a special hardware in it's IO, it's called SEREDES IO, which it can get to 1GHz  and down scale the stream to parallel stream with lower clock inside the FPGA core fabric

[Fungus]

1) You could try soldering wires to the chip and driving it directly but it may not work, depending on what else is connected to the PCB traces.

2) You could sniff the bus at startup using a logic analyzer.

3) The only way to be sure is to desolder the chip, read the contents, put it back again. It's a few minutes work if you've got the equipment, a big hassle if you haven't.

Thanks Fungus 

Option 3 is out of the question. I have neither the equipment or the skill for SMD de-soldering.

Ideally you need hot air bit if it's only an 8-pin chip then removing it with chipquick is probably easier than soldering wires to the pins to sniff the bus:

http://www.chipquik.com/store/index.php?cPath=200

Putting it back isn't difficult either. You don't solder individual pins with SMD, you just put a bit of solder in the general area and rely on the solder mask to do its job. A lot of people use big screwdriver-shaped soldering tips so they can do several pins at once (faster!).

I will go for option 2 - that looks safest. Will practice on dev boards first to prove the principles.

If option 2 does not work, then I will go for option 1.

Much appreciated...

2 is definitely the safest.

1 isn't completely without risk - you'll be applying +/- voltages to bus lines. Don't just short pins to ground, make sure you use resistors to limit the currents. Hopefully the FPGA will set its pins to a sensible, high-impedance state after reading the flash but I have no idea if it does or not - read the datasheet.

Question: Is it necessary to reprogram the FPGA in the initial phase? Can't you leave the FPGA as-is and just work on the main firmware? The most important thing right now is creating an environment where the compile-update cycle is as short as possible. If it takes five minutes to upload/test each iteration then this will go nowhere.

[tooki]

Pull out the plastic bit, the cable should pull out easily then

Maybe this instruction needs to be changed. "Pull out" is wrong, the part isn't supposed to be removed. Just "lift the latch and the cable will release easily."