The Rigol DS1052E

[just]

Hi Meiner, as I can see in the flash file you have changed the serial number before the downgrade...
The two halfs of the flash are quite identical, only 251 bytes are different, more data in the first half. And the *.rgl is with 21 bytes more than 4MB, not 16 bytes. Maybe it will work if you put the file in the lower part of the flash, without the 21 bytes...

regards
Just

[JimBeam]

each half in the bin is 4,194,344 bytes, my 2.02 *.rgl is 4,194,325 bytes. so its 19 bytes shorter? how could you say that it got 21 bytes more than 4MB?

2^22 = 4,194,304 - not 4,194,344

So it is 21 bytes longer.

[just]

Hi, please calculate

8 MB = 8388608 bytes, the size of file.bin, split in 2 and see the size of each one, also compare them
4 MB = 4194304 bytes,

the *.rgl file is 4194325 bytes in size

so the difference are 21 bytes: "DS1000E   02.01.01.00"

[Meiner]

Hi Meiner, as I can see in the flash file you have changed the serial number before the downgrade...
The two halfs of the flash are quite identical, only 251 bytes are different, more data in the first half. And the *.rgl is with 21 bytes more than 4MB, not 16 bytes. Maybe it will work if you put the file in the lower part of the flash, without the 21 bytes...

regards
Just

Hi Just,
you are right, I already changed the serial number. I also thought about writing the *.rgl without the 21 byte header into the forst half of the flash, but after finding out that the flash contains less data than the *.rgl, I'm not so sure to do so any more. I'm afraid of damaging the solder pads on the pcb by multiple soldering/desoldering the flash...
I'm trying to get the contents of a working flash, to find out whether the few data in my flash was caused by the failed downgrade or not. I hope to find out, that the *.rgl is really placed in the lower half of the flash, if so, I can safely program a new flash and resolder it.

So, if someone could post his (working) flash content, I would be very thankful.

[Mechatrommer]

Hi Just,
you are right, I already changed the serial number. I also thought about writing the *.rgl without the 21 byte header into the forst half of the flash, but after finding out that the flash contains less data than the *.rgl, I'm not so sure to do so any more. I'm afraid of damaging the solder pads on the pcb by multiple soldering/desoldering the flash...
I'm trying to get the contents of a working flash, to find out whether the few data in my flash was caused by the failed downgrade or not. I hope to find out, that the *.rgl is really placed in the lower half of the flash, if so, I can safely program a new flash and resolder it.
So, if someone could post his (working) flash content, I would be very thankful.

yup! u ar going to need the good working scope's flash content as we dont know how's the existing file header content will be mixed together with the written firmware by the bootloader. cant you device a way to program the flash on board right away? so to avoid multiple solder-desolder? the existing JTAG maybe? or build a custom parallel interface that pop out of the flash pin on the PCB? this way, we can program the flash and test it as many time we want.

even the 3rd party generic flash reader still quite expensive for me, i'm thinking of building a custom PIC or AVR EEPROM reader for this specific spansion flash, but gotta find a good allocation of time for it, still quite busy for everything rite now
if any existing code for pic or avr for this, i'll be happy to burn it down the pic and start poking out my spansion.

[lynx]

Here is the contents from the flash in my NON-WORKING scope (bricked it while going from 02.04 to 02.02).

I have believe it to be read out correctly but I had trouble with getting all the pins to connect with the socket I had availible.

Anyway, I can confirm that the firmware is in the bottom half of the flash and that it indeed starts with the 21byte header removed.

But I have yet to experiment further until the ZIF socket and spare spansions I have ordered arrive.

[Mechatrommer]

Anyway, I can confirm that the firmware is in the bottom half of the flash and that it indeed starts with the 21byte header removed.

did u mean... not the top half? i saw the firmware is in the beginning of the file
can you provide the link to your 2.02 firmware? coz the 2.02 i have is different in byte content when compared to your bin. only the first 65KBytes is similar.

here's where i got mine:
http://www.rcgroups.com/forums/attachment.php?attachmentid=2866736
if its the same source as yours, then i should re-download and check if any content are changed.

[lynx]

I ment starting at address 0h.

I checked the file in the link you posted and its contains the same data as the file I used. I also compared the contents of my flash with an 02.04 file I found and that to is different (from that point of first difference towards 02.02)

Are there several 02.04 revisions around?

[bushing]

I was trying to figure out the pinning of the internal JTAG header:

[...]
There should also be a 3V3 Pin at least on the header, I haven't checked it yet.

Flash S29GL064N90TFI04 runs at 3.3V, word-mode

CPU ADSP - BF531

    Pin95-BMODE1 = 0V
    Pin96-BMODE0 = 3V3
--> Boot from (16bit) Flash

The CPU's datasheet mentions a internal ROM; I'm not sure if it's really a ROM (meaning that even Rigol hasn't changed it) and I want to find out it's content. My goal is to get access to the CPU via the JTAG interface to try to reflash the FLASH.

Please double-check this; I measured BMODE0/1 and got completely different results, see https://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824.  (I also put the JTAG pinout there.)

The purpose of the ROM is to read those BMODE pins and fetch the rest of the code from the appropriate source ... if the datasheet says it's ROM, it's doubtful that Rigol can reprogram it.

[rf-loop]

I ment starting at address 0h.

I checked the file in the link you posted and its contains the same data as the file I used. I also compared the contents of my flash with an 02.04 file I found and that to is different (from that point of first difference towards 02.02)

Are there several 02.04 revisions around?

I have seen three different 02.04


.00 (maybe never factory installed for markets)
.01 (first factory release "modification disabled FW" after "modification enabled FW" 02.02.SP2
.03 (last known factory release.)

maybe there is also .02 but I have not see.

this last part of FW version number can see only with *IDN? command.
(and of course if read FW file directly)

[shirsch]

Now its getting to be more fun. You're right, only using the *IDN command via the RS-232 port does the full revision number show up. My scope is now at firmware  00.02.04.00.03 .

You can now download this firmware version at the USB upgrade for dummies thread. This file was downloaded directly from my USB stick that was used for my scope.

At the risk of belaboring the point, has anyone verified that a DS1052E shipped with 00.02.04.00.03 can be successfully "downgraded" to 00.02.02 SP2 ?

[Polossatik]

At the risk of belaboring the point, has anyone verified that a DS1052E shipped with 00.02.04.00.03 can be successfully "downgraded" to 00.02.02 SP2 ?

I just updated the guide for this

[Cheshyr]

It must have been an incomplete flash. I inserted an usb stick with the firmware and ran it from the menu system, once it was done I restarted the scope, it was then it refused to start up properly. Strange things go on with the button lights they light up randomly and if i do quick restarts they move...it looks kinda like a counter is incrementing.

spansion?

I can reprogram flash memories and eeproms easily enough, if i have to. But I don't know which parts of the .rgl file to place where.. and in what order ...

I'm watching this thread too.  My symptoms are identical to Halman's.  Expensive brick.

[Mechatrommer]

we found another "bricker"! maybe rigol has take more evasive action for this hack!
can anybody point me to where i can get Spansion Flash cheaper? i need a spare for my rigol and for testing.

[Cheshyr]

we found another "bricker"! maybe rigol has take more evasive action for this hack

I'm going to blame this one on my incompetence.  I didn't get the file or hear about the hack from EEVB.  I ended up here after the fact while searching for a fix, only to find a much more rigorous and professional procedure.  I did a checksum on my file, and it matches the one stored here.  The calibration date was June 2010, which I believe matches with someone else's successful flash.  I think it was just a bad flash; nothing indicated a problem with the downgrade.

Either way, I just wanted to see if someone had found a way to force a reflash or fix it somehow.  My gut instinct thinks we either need to find a way to access the bootloader so we can trigger a 'factory update', or we need to get a complete image of a working flash, and do a full overwrite.  I have no evidence to back this up however.

[slburris]

Someone was talking about looking for JTAG connections a while ago -- did that ever pan out?

Presumably these are manufactured with blank flash soldered in, then they are programmed
via JTAG.  I suppose you could pre-program the surface mount flash in an adapter, but
that seems wrong, since you need to do a final test anyway -- might as well program the
flash at that step.

So if someone figures out the JTAG and images their flash, then the bricked scopes should
be recoverable.

Scott

[Cheshyr]

Someone was talking about looking for JTAG connections a while ago -- did that ever pan out?

Presumably these are manufactured with blank flash soldered in, then they are programmed
via JTAG.  I suppose you could pre-program the surface mount flash in an adapter, but
that seems wrong, since you need to do a final test anyway -- might as well program the
flash at that step.

So if someone figures out the JTAG and images their flash, then the bricked scopes should
be recoverable.

Scott

Ok, I've attempted to RMA my first scope, and I've purchased a second one.  If the RMA gets refused, I'll dissect the bricked scope and see if I can find a way for other people to recover their bricks.

On projects I've worked on in the past, the entire board was manufactured, and the flash was programmed after first-pass electrical test and AOI.  If they were using a ROM of some sort, I'd think they would program the device prior to manufacturing.  They're using Flash, which implies they had a reason to want to flash it after assembly, and that there's a mechanism to accomplish this.  That said, it might not be a straight-forward procedure.  On the same project I mentioned above, we wrote a custom bootloader, and encrypted our firmware.  The bootloader would decrypt it, verify a hashcode to ensure the firmware wasn't corrupt, and then dump the firmware in it's appropriate location.  (Branding requirements are always fun.)

With regard to our specific problem, I think the easier solution is to get a complete dump of a working flash, and overwrite the entire chip.  Preferably, a working flash from a DS1052D or E that's already been modded, or one that is running 2.02.  In theory, this should bypass any potential weird bootloader issues, and get us into a state where we can go about fixing the serial number, model number, and updating the firmware accordingly.

[shirsch]

At the risk of belaboring the point, has anyone verified that a DS1052E shipped with 00.02.04.00.03 can be successfully "downgraded" to 00.02.02 SP2 ?

I just updated the guide for this

Thanks much!  Chalk up another successful mod    Went just as advertised.   This unit had a calibration date of June 8, 2010 and shipped with firmware 00.02.04.00.03.

[drieg]

@lynx
@Meiner

I could be of any help reconstructing your FLASH content. The vital data seems to be OK in both cases. Could tell me the HW version (e.g. "DEM07") and the PCB version (e.g. "0941") of your scopes?

[Meiner]

Hi everybody,

sorry for my late reply, I`ve been busy with other topics... also, I've ordered another new DS1052E to desolder the working spansion and read the content. But on the other hand, I need a scope right now and this one's working... I will continue my repair trials in some weeks.

But I have yet to experiment further until the ZIF socket and spare spansions I have ordered arrive.

@lynx: could you pls tell me where you ordered a ZIF? This would help me a lot. Thanks

Please double-check this; I measured BMODE0/1 and got completely different results, see https://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824.  (I also put the JTAG pinout there.)

The purpose of the ROM is to read those BMODE pins and fetch the rest of the code from the appropriate source ... if the datasheet says it's ROM, it's doubtful that Rigol can reprogram it.

@bushing: I can check this at the end of next week, since the open PCB is not here right now.

we found another "bricker"! maybe rigol has take more evasive action for this hack!
can anybody point me to where i can get Spansion Flash cheaper? i need a spare for my rigol and for testing.

@shafri: I got my spansion at www.mouser.com: 797-S29GL064N90TFI04 (EUR 4.60)

@lynx
@Meiner

I could be of any help reconstructing your FLASH content. The vital data seems to be OK in both cases. Could tell me the HW version (e.g. "DEM07") and the PCB version (e.g. "0941") of your scopes?

@drieg: Thanks for your offer, next possibility to get the version is end of next week.

Thanks Meiner

[Mechatrommer]

I've ordered another new DS1052E to desolder the working spansion and read the content. But on the other hand, I need a scope right now and this one's working... I will continue my repair trials in some weeks.

you really got balls! be careful with the new one.

[shirsch]

I'm a bit new to DSOs, so pardon me if this is a naive question.  Should the trace on my DS1052E show "fuzz" on the top and bottom of the waveform when viewing the calibration square wave?  I would have thought the signal was well out of the noise and expected to see a rock solid display.

[lynx]

>>drieg


Hello, it would be awesome if you can do anything to help! Here is the information you requested:

PCB rev: 10 12
HW rev: DEMO7

>>Meiner

I bought them off ebay, I have yet to recieve them.

[mxmxmx]

I'm a bit new to DSOs, so pardon me if this is a naive question.  Should the trace on my DS1052E show "fuzz" on the top and bottom of the waveform when viewing the calibration square wave?

Yes, it is normal to see that, since the ADCs add some noise to the signal. (This, by the way, also applies to much more expensive Agilent or Tektronix DSOs.)

[alm]

Indeed, and there's likely to be noise on the original signal (no signal in the real world has zero noise). Turning on averaging or bandwidth limiting should reduce it, and turning on peak detect should make it worse. As long as it's not too much (<= .1div or so, depending on bandwidth, acquisition mode and vertical sensitivity?), you shouldn't worry about it, and just get used to seeing it. I would be suspicious if I saw a completely clean signal. Using a shorter ground lead may help if you want to reduce it, Bob Pease has a good write-up about noise in scope shots.