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?
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.
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.
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.
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?
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 ?
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 ...
we found another "bricker"! maybe rigol has take more evasive action for this hack
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
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
But I have yet to experiment further until the ZIF socket and spare spansions I have ordered arrive.
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.
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.
@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?
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.
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?