Agilent 34405A Bricked - FIXED! - Page 1
Forum section: electronics / testgear

author: oriolsancheza
author_rank: Contributor
timestamp: November 29, 2016, 10:22:05 am
content: Hi guys,I'm pretty sure most of you knows that this one had a lot of problems with usb connection. Well I decided to upgrade it from the original firmware to last one. After many attempts and 4 computers I finally were able to connect it and do the upgrade.Everything went well until last phase when it resets the unit. The updater gave me an error and the DMM was in "download" mode but not responding. I wasn't able to connect it again so I decided to turn it off and on again because the upgrade was done till "reset" so I thought that fw was already uploaded.Well.. it hasn't powered on again, so now I have a 400 bucks thing with about 5kg on my desktop..I have seen it has a Microchip dsPIC and an AT91 microcontrollers... I was wondering if some one here can try to read them and help me to rescue the unit!!! I'm not sure if code is protected but in any case, maybe the one on the "programmer" will be readable.BTW, I've read somewhere that this DMM was not an Agilent development, but I wasn't expecting to see a "Jing Li" mark on PCB...I really appreciate your help to fix my unit.Thank you very much!Best,Oriol.

author: HighVoltage
author_rank: Super Contributor
timestamp: November 29, 2016, 11:59:22 am
content: Unfortunately there have been several reports of this failing FW update on the 34405A and many have been bricked. I have not heard of any that have successfully un-bricked it. I used to have on of these, also tried to upgrade the software and it did not work. Luckily it was not bricked and I sold it in a good working state.The service guide is very limited and has no schematics.You probably have to find someone with a working 34405A and transfer the FW manually, if that is possible.

author: oriolsancheza
author_rank: Contributor
timestamp: November 29, 2016, 04:26:27 pm
content: Thanks! I tried to read the dspic30 and the atmel sam7 with succes!! But.. corrupt code.. it seems to be not protected so if some one with a working one can read it, I will be able to burn the fw manually.I hope I can dot that because this will help many people also with the same problem.Let's see if someone can do it.Thanks.Oriol.

author: TheSteve
author_rank: Unknown
timestamp: November 29, 2016, 05:26:49 pm
content: Wow, I haven't seen one truly bricked before. I would guess the PIC firmware is the one causing the non-boot problem since the machine can run without the Atmel arm board. You can find the Atmel firmware in this thread with some info on how to flash it:https://www.eevblog.com/forum/testgear/agilent-34405a-schematic-and-the-infamous-635-error/msg1068325/#msg1068325I haven't spent anytime looking at the PIC as my unit now works 100%.

author: nctnico
author_rank: Super Contributor
timestamp: November 29, 2016, 06:51:46 pm
content: It seems there is a programming header next to the PIC so if someone could try and extract the firmware it may help others.

author: TheSteve
author_rank: Unknown
timestamp: November 29, 2016, 07:27:47 pm
content: I'm happy to try reading the PIC if I have a compatible programmer. I doubt I do though.

author: oriolsancheza
author_rank: Contributor
timestamp: November 30, 2016, 12:02:45 am
content: Thanks for replies!! And thanks for the link Steve, it's very useful!! The header next to the PIC is standard ICSP port, I have checked it! Easy, just connect.. and read/burn. I've did it with an old pickit 3, I'm not sure if pickit 2 is compatible with these dspic30F series.I will try to burn the fw onto SAM7 tomorrow, but will be great to get the PIC fw too. We can try to make a little tutorial and code links to help more people to fix that problem.Thanks!Oriol.

author: TheSteve
author_rank: Unknown
timestamp: November 30, 2016, 02:19:30 am
content: I'm not a PIC guy at all but do have a pickit II if that will work.

author: oriolsancheza
author_rank: Contributor
timestamp: November 30, 2016, 12:38:06 pm
content: That dsPIC30F6013 is not compatible with Pickit 2, It says unsuported part. BUT, I have edited the .dat file to include compatibility.Just replace your .dat file on Pickit 2 folder with the one attached, and you will be able to read it!https://www.dropbox.com/s/n2hnk2jojdko4ef/PK2DeviceFile.dat?dl=0Pinout:I will wait for your news Steve! Thank you!Best,Oriol.

author: MosherIV
author_rank: Super Contributor
timestamp: November 30, 2016, 02:38:38 pm
content: Have you tried asking Keysight (formaly Aglient) about getting it repaired ?

author: oriolsancheza
author_rank: Contributor
timestamp: November 30, 2016, 06:28:37 pm
content: Quote from: MosherIV on November 30, 2016, 02:38:38 pmThe unit has about 10 years, so no warranty. Anyway I think this is not covered by Keysight.. a bad thing but afaik..Let's see if Steve can read his unit and post the .hex!!Best,Oriol.

author: TheSteve
author_rank: Unknown
timestamp: December 01, 2016, 05:25:55 am
content: Fired up the PICKIT II and attempted to read the processor. It gets to about 20% and then hangs for 10 seconds, then responds again and claims it finished. Two reads gave me the same info but I find it unlikely the reads are good.I will PM you a download link oriolsancheza so you can look at the file. I doubt it is good so I don't want others downloading it.

author: oriolsancheza
author_rank: Contributor
timestamp: December 01, 2016, 08:57:35 am
content: Quote from: TheSteve on December 01, 2016, 05:25:55 amBack to life again!! Thank you very much!! Now It gives me error 635, but it's due the atmel fw is still corrupted. In any case, the unit seems to work well, I will do some test.Im gonna make a small tuto on the first post to help other people.Thanks!!Best,Oriol.

author: HighVoltage
author_rank: Super Contributor
timestamp: December 01, 2016, 09:30:53 am
content: Congratulations, well done.

author: TheSteve
author_rank: Unknown
timestamp: December 01, 2016, 05:09:02 pm
content: Wow, nice. I really didn't think the file would be any good. Glad it worked.Before we post the file for anyone to grab it would be nice to know where the calibration info and serial # are stored. When you reflash the Atmel ARM the 635 error should be gone. At that point it is easy to query the serial # via USB. You will have to see if it your original #, blank or if it now has mine. Obviously any serial # beats having a bricked meter but it would be nice to be able to tell people what they might be losing when flashing the file.

author: oriolsancheza
author_rank: Contributor
timestamp: December 01, 2016, 06:30:44 pm
content: Quote from: TheSteve on December 01, 2016, 05:09:02 pmNo problem, the SN is on the Atmel FW, in fact, take a look to the .bin file of the SAM7:It's quite easy to edit and change it, you just need to know your unit SN (usually always on the rear as you know), and paste it.Thank you!Best,Oriol.

author: TheSteve
author_rank: Unknown
timestamp: December 01, 2016, 07:00:09 pm
content: Thank you for the info.I have attached the PIC firmware to this post.edit - changed the name of the file to reflect that the file is version 1.50 which is the newest available.

author: TheSteve
author_rank: Unknown
timestamp: December 02, 2016, 03:26:26 am
content: Quote from: oriolsancheza on December 01, 2016, 06:30:44 pmI'm not so sure editing that will change the serial #. That is the file I flashed into my 34405A Atmel ARM yet I still have the correct serial # even though I didn't edit the file.My cal data is also still bang on even though I have reflashed the Atmel ARM.Unless there is more memory on board(I haven't really looked) I'd say the cal data must be in the PIC.

author: oriolsancheza
author_rank: Contributor
timestamp: December 02, 2016, 11:15:52 am
content: Quote from: TheSteve on December 02, 2016, 03:26:26 amWell as the PIC hasn't USB I guess that engineers decided to opt for a second micro to run it as firmware burner and as remote master with USB. I still don't know why use an ARM7 device for that purpose but it's okay.. in any case I haven't seen any SN on PIC FW, only on the Atmel one, and it make sense. Despite the Atmel ask to PIC everytime to send him the SN, probably the PIC only has the main FW and calibration data, etc.. I haven't seen any eeprom on the board for calibration settings but could be possible.As soon as I receive my new jlink I will do further investigations about this, because mine now only can read but no program ARM7 series (don't ask me why). It's rare that you still got your SN after flashing the ARM.. I will double check it when it arrives.Best,Oriol.

author: pigrew
author_rank: Frequent Contributor
timestamp: December 25, 2020, 06:37:33 am
content: I've repaired a 34405A by re-flashing the dsPIC30F microcontroller. The symptom was a blank display and no beep when power is turned on. Also, I was unable to connect to the DMM via USB. It turned out that the first few words of the dsPIC's flash were set to 0x000000.The calibration and serial numbers are stored in the internal EEPROM of the dsPIC30F. If one alters the EEPROM, the serial number reported over USB is changed. The manual mentions a CRC check in the EEPROM, but I'm not sure if it protects the serial number or not. The "secure code" has to be somewhere, too, but I'm yet to find it.The PSU board has a serial flash IC, but I don't think it's normally used. (Perhaps it would be for some other model, or maybe used during firmware upgrade?).I recovered the dsPIC30F using a counterfeit PicKit 3. JP12 (2mm pitch) pins 1 to 5 are the programming header. Pin 1 is towards the rear of the unit, and the pin order matches the PicKit's pins 1 through 5 (leaving 6 empty).During re-programming, I disconnected the communications cable to the PSU board (JP3), to prevent any sort of shenanigans. I made a backup of the EEPROM table (through MPLAB X IPE). I then erased the chip and performed a blank check. I imported the previously posted memory dump into IPE and then used EEPROM "load table" to load the EEPROM backup (including calibration coefficients and serial number). After that, the DMM came back to life.(I did have to repeat this process twice. After the first time, nearly all of the program flash was set to 0x00. I wonder if it was some order-of-poweroff that I did, or maybe the PSU board's USB interface processor had commanded the dsPIC to reprogram itself. I'm not sure.)I think that the EEPROM could be updated via USB (DIAG:UPD:BLOCK?, DIAG:UPD:BLOCK:CODE:LOW? , DIAG:UPD:BLOCK:PROG?, and DIAG:UPD:BLOCK:FLASH commands, but I'm not sure which particular arguments to give them (and it could easily brick your DMM if you use the wrong parameters.)During this ordeal, I reverse-engineered the PSU board,and posted the schematic in this other thread.