| General > General Technical Chat |
| The Rigol DS1052E |
| << < (82/166) > >> |
| Rodan:
Just for kicks I tried Visa 4.6.2 and it also works fine. As a side note, since upgrading to 100MHz has anyone experienced any weirdnesses with calibrating the probes that came with the unit? After going to 100MHz unless I turn BW Limit on when I calibrate the probes, I get a very jumpy square wave that won't lock on using auto acquire, or even manually trying for that matter. ??? My guess is since the BW has increased to beyond 100MHz, it is picking up some very high order harmonics or some interference from the rudimentary square wave generator built into the scope and causing the scope to trigger improperly. As a test I tried using some 60MHz probes I had laying around for another scope, and they don't exhibit this problem. I also never experienced this problem until I modded to 100MHz. Oh, well I just thought it was an interesting problem and also shows that the BW must have increased. Does the DS1102 come with the same probes? If so, does it have this goofy behavior when trying to calibrate the probes? |
| Mark_O:
Rodan, > Does the DS1102 come with the same probes? < Same as what? ;) What's the partID on your probes? I.e., RPxxxx. I think the 1102E's ship with RP1300's (rated 300 MHz @10x). I got RP3200's with my DS1102CD (rated 350 MHz). BTW, the Cal output is only 1 kHz, so I'd be surprised if it had significant harmonics beyond 100 MHz. Stick your probe on there, and run the FFT on it. - Mark |
| rf-loop:
I have some of both DS1102E and DS1052E's. Both models come to me in Rigol original factory packages. All both models have RP2200 (rated as 150MHz @ 10:1) I have make parallel tests with commandmodified machines (no hw mod). original 1102 modified to 1052 and original 1052 modified to 1102. No other differencies but normal variations between individual units. Differencies are not markable between individual units, normal (maybe) random small differencies. All units are arrived FW020202. I have not see any difference in probe cal output after mod. Allways remember run selfcal after modification. (after 30minute warm up and nothing connected to any scope I/O) My opinion is that problem is now somewhere else than mod itself... but also there need be careful with opinions becouse there are slight product variations and different HW revisions... |
| Simon:
--- Quote from: Rodan on March 23, 2010, 05:29:40 am ---Just for kicks I tried Visa 4.6.2 and it also works fine. As a side note, since upgrading to 100MHz has anyone experienced any weirdnesses with calibrating the probes that came with the unit? After going to 100MHz unless I turn BW Limit on when I calibrate the probes, I get a very jumpy square wave that won't lock on using auto acquire, or even manually trying for that matter. ??? My guess is since the BW has increased to beyond 100MHz, it is picking up some very high order harmonics or some interference from the rudimentary square wave generator built into the scope and causing the scope to trigger improperly. As a test I tried using some 60MHz probes I had laying around for another scope, and they don't exhibit this problem. I also never experienced this problem until I modded to 100MHz. Oh, well I just thought it was an interesting problem and also shows that the BW must have increased. Does the DS1102 come with the same probes? If so, does it have this goofy behavior when trying to calibrate the probes? --- End quote --- the DS1052 probes are rated at 150 MHz, I've had the same calibrating problem but I beleive i may have had it before as well, could be a burnt out generator ? maybe retry with a 555 generated signal ? |
| bushing:
--- Quote from: Mark_O on March 20, 2010, 03:56:35 am --- --- Quote from: bushing on March 15, 2010, 12:19:30 am ---The firmware images don't appear to be signed, so they could be modified easily --- End quote --- I wouldn't be so sure. --- End quote --- Oh, don't worry, I'm rarely sure of anything :) I did later amend some of this to reflect some uncertainty -- https://www.eevblog.com/forum/index.php?topic=30.msg2824#msg2824 --- Quote --- --- Quote ---There's no room for a hash, so you could do whatever you want to the file. --- End quote --- There's no room for a hash in the header, but that desn't mean that one (or a CRC) isn't embedded in the firmware images, to detect corruption or tampering. --- End quote --- [ "Hash" was a poor choice of words on my part. There's no obvious sign of a cryptographic signature, or a hash, or even a CRC. The former would be the only real form of protection that would let them "fix" the problem -- the latter two could be reversed, given enough time and energy. I've yet to see a system that used hashes or signatures that didn't have them in a fairly obvious spot. Especially if there's a nice header with other metadata. Doesn't mean it couldn't happen, but I find it unlikely. --- Quote --- --- Quote ---Unfortunately, this means that there's no sort of bootloader which could recover corrupted firmware, so your options would be to desolder the NOR flash holding the firmware and reprogram it using a chip programmer, or try to get the 13-pin JTAG-looking connector working. --- End quote --- Actually, there IS a bootloader in the BlackFins, in protected space. But I doubt it would have the ability to read files off a USB stick. So in that sense, you may be right that once corrupted software was loaded, recovery would be difficult. OR, they may have a dual-image system, where they can load a 2nd set of firmware into the other half of Flash, but not toggle control over to it until it had been successfully validated. Otherwise, once they started a reflash cycle, they'd have to blow away the original firmware first. From which point there'd be no recovery on power fail or by the time it knew the image it loaded was bad. That could explain how they utilize 8 MB of Spansion Flash, when the firmware only occupies 4 MB. And during operation, the remaining 4 MB can be scratchpad space (like 1 MB for Reference waveform memory, as Andreas and Drieg pointed out). --- End quote --- I was just plain wrong about the bootloader. There are at least two, one of which has me mystified: 1) There's the BlackFin standard bootloader, the one you're referring to. It can boot from a NOR flash (or other external memory), or a SPI master, or a SPI slave, depending on strapping. (Ref: http://www.analog.com/static/imported-files/data_sheets/ADSP-BF531_BF532_BF533.pdf page 14) 2) There is an unknown mystery second-stage bootloader somewhere. BMODE1 is tied hard to Vcc, and BMODE0 is pulled low with a resistor, which means that the BF is acting as a SPI slave, and being fed code from some unknown place over SPI. It's possible the entire firmware is loaded over SPI, but it doesn't seem likely to me (not in the normal boot case). That being said, I can't find any place where that could be coming from -- nothing looks like a SPI flash, and 15 minutes of poking around with a DMM didn't find anything connected to the SPI lines except for the edge connector. The only place I can think that they might even be possibly hiding it would be the Lattice CPLD, but I couldn't find any connections between the BF's SPI bus and the Lattice chip. I think that that second-stage bootloader is probably fairly small, and it probably loads the rest of the firmware from the NOR flash. I don't know why they bother doing this, instead of booting from the NOR flash directly -- they could be doing some sort of verification in there, but my gut feeling says they're not. The SPI lines (as well as BMODE0 and PF2 aka SSEL) are run out to an edge connector right next to the I2C EEPROM, and I believe this is what is used in the factory to load the initial firmware onto the device. These same SPI lines should be what carries the normal bootloader, but I haven't had a chance to open my scope back up and watch those lines with an LA -- if anyone else does that, I'd love to hear about it, because now it's bugging me. :) The dual-image idea doesn't seem very likely to me either -- but at this point, I'm just guessing because I have nothing to go on and am too much of a coward to risk bricking my scope to prove a point :( |
| Navigation |
| Message Index |
| Next page |
| Previous page |