Rigol DG4000 power rails failure and firmware bricked

[Fabian]

Hi,

I own a Rigol DG4162 and I am very happy with the device - except for a few software things I don't like...
However, a few days back I turned it on after not using it for a few weeks (maybe month) and it hang during boot process. The GUI was fully loaded but I was not able to do anything. I unplugged it and tryed it again, it hang again during boot at some other point. I tried this a few times, however it hang at different points in the boot process.
Well, I assumed an hardware fault, because a software issue would probably not be that random. Nevertheless I updated the bootloader and the DSP firmware according to the instructions. I had to reboot it several times after it did not finished after half an hour. Doing that obviously bricked it. Then it just turned all LEDs on when I hit the power button and nothing else happens. I cannot bring it into the mode to update the firmware any more (pressing the Help button at boot up). So my first question: Can I somehow recover the firmware?
Now the second problem: I assumed a hardware fault from the beginning. So after I software-bricking it, I took it apart and did a few tests. Visual inspection is ok. But there are two voltage test points which are not ok. The 1.5V rail has 3.3V and the 9.9V rail (something for/from the display) also has 3.3V. Well, I focused on the 1.5V rail first, as I could not find the source for the 9.9V rail and this might be due to the broken firmware (backlight stuff). The 1.5V regulator is quite strange, I attached an image of the circuit and a schematic I reverse engineered. What kind of regulator is that with the feed-back network at the input? The only thing I can image is an emitter follower. Theoretically it might be possible that this is actually a regulator from 1.5V to something lower but then the labeling would be very confusing, I don't know where the 1.5V are coming from, there is no test point for the output and there would have to be a short between the output and 3.3V.
Next thing I did was removing the regulator and this changed nothing. There is still a resistance of ~10R between 1.5V and 3.3V (both polarities).
Is there any one who had a simular fault? Or any other idea how to track that down or even fix it?
Rigol offered me to replace the mainboard for 520€ and/or the power supply for 270€ - I am out of warranty :-(

Best regards,
Fabian

[ivi_yak]

hi,
I have same problem, brick after update firmware
Did you find solution how to repair firmware

[Fabian]

Hi,
I would like to push this topic back to the top, as I stumbled accross the old PCB (which I got when Rigol replaced the mainboard). As I now have a working and a non working board, I can compare them and was hoping to be able to revive the old (defect) board. I already tested that it only required the power supply and is ready to be used as a purely remote controlled generator. Might come in handy one day to have a second one
I did a few more things and have a few questions:
* All voltages seem to be fine, including the 1.5V rail. Don't know what the problem was. Maybe resoldering the regulator did the job.
* I was able to talk to both FPGAs using JTAG, but I was not able to read any of the memory from them. The ProASIC 3 cannot be read back. It has internal flash and there is nothing I can do about it, if it is faulty. I also guess the firmware is not included in the firmware updates. The FPGA that does the heavy lifting (under the big heatsink, connected to the DAC), is a Xilinx Spartan 6 XC6SLX25. I was not able to find any flash chip on the board for that device, so I guess the firmware is pushed into it by the DSP on every boot. Can someone confirm this?
* All clocks seem to be ok.
* None of the chips (2x FPGA, 1x DSP) is doing anything. I mean like nothing at all. I cannot even pick up radio emmissions from them using a near field probe, while I defenetly can on the new board. It seems like they are in reset state. However, the main reset line I identified is high, so seems to be ok.
* My guess is that the DSP is not running at all, because I bricked the firmware. As the DSP is responsible for programming the Xilinx, the Xilinx does not do anything. As the only clock line I could identify going into the ProASIC3 seems to come from the Xilinx, the ProASIC3 is not doing anything.
* So, I would like to reflash the firmware of the DSP using JTAG. I used a general purpose FT2232H, wired it up according to https://www.eevblog.com/forum/testgear/dg4000-a-firmware-investigation/msg269620/#msg269620 and used TopJTAG. TopJTAG found the DSP and I have to specify a hole bunch of stuff about the flash. I have not even found the flash on the board. Like there obviouly is a place to put a flash chip, but it is not populated. There is an additional FRAM which is connected using I2C. Is that where the program lies? The ADSP is capable of booting from I2C, but I do not see what to put into TopJTAG to get this working. Any help is welcome.

[Fabian]

Just got step further... I read the mentioned thread again and realized that TopJTAG was not the recommended program. *cybernet* was using the linux blackfin toolchain, which you still can get here: https://sourceforge.net/projects/adi-toolchain/
After fiddeling a bit, I was able to connect to the DSP:
./bfin-gdbproxy --debug bfin --frequency=6000000
I did this with just an FT2232H I had lying around. It did not worked out of the box, I had to change the USB PID to baf8 (VID is still 0403 - aka FTDI), which is an "Amontec JTAGkey".
Now my new question is: How do I read/write the flash with the toolchain?

[Fabian]

I guess I will use this thread just for reporting my progress Maybe someone else can use it.
I was able to read/write the flash of the DSP. I am using Ubuntu 18.04. After downloading the toolchain:
$ tar xf blackfin-toolchain-2014R1_45-RC2.x86_64.tar.bz2
$ cd opt/uClinux/bfin-linux-uclibc/bin
$ sudo ./bfin-jtag -q
You can also do it without sudo, but you probably (like me) would have to fiddle around with udev to get the right permissions on the device first
> cable OOCDLink-s
Connected to libftdi driver.
> detect
Should give you a list with some info on the device like ID, Manufacturer etc...
> initbus bf52x
> detectflash 0x20000000
Should give you a bunch of info on the flash, like voltages, timings, size, ...
> readmem 0x20000000 0x1000000 flash.bin
This will read the flash into flash.bin. I hope that command is correct, aspecially the size. Should be 16M as reported by detectflash, but according to the memory map of the Blackfin it has only 4 banks of 1M for flash... I don't get it, just hope it will work.
After that I connected the defect board, did the whole progress with bfin-jtag again but instead of reading I wrote the flash:
> flashmem 0x20000000 flash.bin Edit: Don't do that! I guess I broke something in the DSP with that command 
Reading takes quite a long time (5 min or so) and writing is even slower...but it will hopefully do the job.

urjtag (which is bfin-jtag) should also support FT2232H directly by changing the cable name from OOCDLink-s to FT2232. I haven't tried it, because "never touch a running system".

I am a bit worried about the flash file. After compression there are only ~980kb left. There are quite a lot FF in there. I also attached the file, maybe it can help someone. I will get back here, when the flash process has finished, guess it will take nearly an hour.

[Fabian]

Two more things I learned so far:
* Using the FTDI directly without modifying the USB PID does not work for me - he is complaining that he cannot open the device or something like that.
* Writing is even slower than I thought - takes about 2 hours
* I guess I did something to the DSP while writing the flash as described above. The flash is not detected any more. I started a new thread to figure out what the problem is or how to read/write the flash of the DSP: https://www.eevblog.com/forum/microcontrollers/readingwriting-adsp-blackfin-flash-problems/

[Fabian]

OK, the DSP is still ok. There is just an additional problem with the reset line that goes to the flash chip. It is not really high. I Added an additional 10k pull-up to overcome this issue, although the line already has an onboard pull-up of 10k. So there is at least one chip doing weird stuff.
I also found out that the data I read from the working device is actually only 1M and then repeats the same data 16 times.
However, reburning that 1M did not helped the instrument. Still no sign of life

[m3vuv]

reminds me of a chineese phone i had,every couple of months would bootloop for no apparent reason randomly,had to reflash the firmware every time,after the 3rd time i binned it,it was called a uhappy,its like the name was taking the piss!!hope there nuke control sw is less buggy!!

[tautech]

@ Fabian
There could be some issues in the PSU's that explain unexpected behaviour.
Member Bud investigated these in depth here:
https://www.eevblog.com/forum/projects/project-yaigol-fixing-rigol-scope-design-problems/

[Fabian]

Hi thanks for that thread... quite interesting.
I have not read everything yet, but what does the PSU (Power supply unit?) has to do with that? Looks like its all about PLL/RF stuff. I had a look at my main PLL for the high speed DAC, but as expected, it is not running, because there is not firmware that might have programmed it to do something. Of course there is an ouput, but that is not locked.
It would be great if someone could tell me how to read/write the full flash of the DSP. I was hoping to get to device back in the sate where it started but randmly crashed during boot.