-
Hi, somehow I've managed to brick my UPS.
Not the NMC but the actual ups. I've tried the serial cable firmware update tool but to no avail.
I took the controller board out and discovered it's an STM32F103RC and they have very helpfully populated a SWD interface, so I dumped the ROM but the provided firmware file is not in a format I can figure out. (Both attached).
Any ideas what to do next?
-
No idea if this is ok for that model:
https://www.eevblog.com/forum/repair/repair-help-for-apc-ups-br1500g-f06-error/msg5074456/#msg5074456 -
i dont see anything attached
darkspr1te
-
Yes, almost at the end there's an hex file!
-
Sorry, the attachment didn't attach! It's on the first post now.
-
file wont unpack, says un-supported 7z method,
-
hmm I've noticed winrar doesn't like those files. Here is a zip. (I hope!)
-
Better don't attach it here unless proved working, it's for a different model and might induce confusion.
-
Ok, well for anyone who finds this post later here is the pinout:
6 - Reset
5 - Ground
4 - PB3 / JTDO
3 - PA14 - SWCLK
2 - PA13 - SWDIO
1 - VCC
It's the white connector in the photo.
I'm toying with the idea of buying another unit of ebay and then selling it once I fix mine. Will post the firmware if I manage to get it.
-
Hi,
ARM STM32F103_C4 (IC603) data exchange with the main MPU 89C51RC -UM (IC11) occurs through connectors J710B-J710B (pin3-TX, pin4 -RX).
These buses (RS232) are also connected to the J606 pin3-TX technology connector; pin5 -RX.
This is the only connector through which you can access SW or perform calibration (in the traditional sense).
In this case, the module itself (PCB: 640-3081J-Z-001 _IMG_) must be removed.
As far as I understand, APC (Schneider Electric) planned to use technology for managing and servicing UPS of this generation via the cloud and, probably, by for this reason it was created.
ARM STM32F103_C4 (IC603) communicates with the control/display panel, NMC and RJ50-10 RTU.
Moreover, the navigation buttons are controlled based on ADC (PB1 pin27) and resistors corresponding to the values of:
-R200-604E “DOWN”;
-R201-1.2k "UP";
-R202-2.43k "ENTER";
-R203-3.01k "Escape"
All of them are connected to the midpoint of the divider made of resistors
(R205-2k +5V) * (R203-3.01k GND).
Pins PB10-pin29 (TX), PB11-pin30(RX) via IC601 (MAX3232) are connected to the RTU connector RJ50-10 pin2 (TX) and pin 8 (RX).
Pins PA2-pin16 (TX), PA3-pin17(RX) - directly via connectors J702B/J702A (pin5-RX, pin6-TX) connected to connector J2 and via a cable to NMC (AP9630, AP9635 pin8/9 [SUMX v6. 4.6]).
J602 JTAG - connector for programming the module and binding to a specific type of UPS.
IC904 93LC66 can be read. Most likely it's MAC/WWN.
SW update is carried out via NMC.
Most likely you downloaded the wrong version.
-
You can find answers to many questions and the firmware you need on the forum:
https://community.se.com/t5/forums/searchpage/tab/message?advanced=false&allow_punctuation=false&q=STM1500
-
I apologize for the boring description, there is no other way. -
Oh, so it's likely the 89C51RC/93LC66 with bad firmware then?
It's strange that I get no response trying to communicate via the RTU port. I made a cable according to https://pinoutguide.com/UPS/apc_0625_cable_pinout.shtml which matches what you wrote, I checked for continuity to the pcb pins as I was using a RJ45 connector. Perhaps I should have tried swapping tx/rx?
I've since seen a few other posts from people who had timeout errors like me when trying to flash via the web interface on the NMC, but I'm not sure if any of them managed to resolve it. -
Hi,
Just bricked my smt1000i also during a firmware update.
Luckily i got it for cheap so it isnt a huge loss but ill see what controlboard mine has.
edit: Tried the exact same firmware version you did....
Edit2: Mine has a 640-3081A_REV06 board. dont know if thats the main one. -
Hi,
You can see everything written above at this link:
-
I also bricked my SMT1500 trying to update the UPS firmware.
Some of the info in this thread is way over my head but still curios to know if you were successful in recovering the UPS?
My control board appears to be 640-3081_REV03.
My unit is a 2011 manufacture date so about time to retire it anyway but it would be nice to recover it.
Bruce -
Hi PeeJay,
I'm also in the same boat with a Bricked SMT1500. BUT I have TWO working ones, one with ID17 and the other with ID18 chip for the main device. This latter one I picked up brand new back in the day and acquired my 3rd one from Ebay for $250.
The Ebay one is also ID18 and unfortunately the one I bricked, as the original firmware for the sub board which was 9.2 and attempting to upgrade it to 15.0 is where it went awry.
So down the path of scouring the internet I come across this forum and your posts.
So it got me to thinking and sure enough my working UPS with ID18 has the same part number (640-3081A-REV006). But I needed to READ the EEPROM chip on the working one on the sub board you have displayed. The chip is an 8 pin SOP and marked 93LC66B1.
This is a 4kbit EEPROM arranged in 256x16 configuration. After googling it and I found a programmer that supports 34,000 different chips on Ali-express (T48 programmer to be precise) with the right connectors etc.
I subsequently took my working UPS off line and removed the sub board and read the EEPROM after some fiddling to get the clip to connect properly. So I have a BIN file with the contents (I'll attach later). BUT upon trying to program the chip on the board from the bricked UPS, I get the error message that the EEPROM failed to be written too. the reason for this is because it's "In Circuit" and I need other connections to my programmer for me to attempt to do it that way. (Currently on order).
Also I noted while I had the bricked UPS disassembled. Their is another EEPROM on the main board near ID18 (AT89C51RC) Which is IC 303 and is an 93C56 chip which is a 2KBit chip (256x8) Which I have yet to read on my working UPS.
So yeah a fun project to say the least and hopefully one that will have a good outcome.
I have also ordered some 93LC66B1's and have the equipment to replace the onboard one if all else fails.
Just change the extension from "HEX" to "BIN" and you'll be fine, Forum doesn't like BIN files
-
Well after getting a programmer and then the correct accessories to do the job at hand.
We discover that the chip (93LC66B1) holds only the serial number of the device and other configuration information.
Having acquired 10 of these devices and reprogramming said device OFF the sub board as they won't program ON board.
We powered up the UPS expecting LIFE to come back. But alas this wasn't the case.
Delving further into the main board and observing those 6 pins. We are of the assumption that they are an ISP connector for programing said device and so forth. BUT we will need to investigate this further.
Having bought an ISP programmer (Dirt cheap) we will see where this goes.
I also have some AT89C51RC chips in the post which is a micro controller with 32KB of memory on board. Yes we have the DATA sheets on these too...
This is an interesting project.
Anyone else with updates to this issue. Anyone resolved it yet ??
Also will do some more research. Gotta be information on the devices somewhere.
-
I've also recently bricked my SMT1500. It's also a 2011 model year with the same board 640-3081A_REV06 noted above. That said, I'm following this thread carefully to see if anyone can figure out how to get this working again. I'm of little help when it comes to circuit knowledge but not afraid to get my hands dirty either.
In the interim, I had to break down and purchase another SMT1500 (2010 model) on the cheap. It's being shipped so not sure what rev board is on the 2010yr model. Don't know if they can be swapped if they are different either.
What is disappointing is that APC should be reaching out and owning up to this bricking problem. They just shrug it off and state that you should not update or should call first. I'm obviously not the only one that has bricked the unit going from 9.04 ID18 to 15.0 ID18. They should probably pull that firmware to figure what's going on unless it's by design....I have other SMT750's that I had no issue with updating firmware. One dated from 2011 and another 2022.
Peter
-
Hi,
??? ҐS361030X7272 mSra-tPUS5100 MS1T05I0 FFFFFFFFFFFFFFBR7C FFFFFFFFFFFFFFOltteG orpu1 FFFFFFFFFFFFFFPU SuOltte s ?? FF??ґ?FF????FF?
?
?FFFFFFFFFeSvrreU SPFF
====
??? ҐXS6301032727 Smart-UPSS1500 SMT1500I FFFFFFFFFFFFFFRBC7 FFFFFFFFFFFFFFOutlet Group1 FFFFFFFFFFFFFFFPSU Outlet s ?? FF??ґ?FF????FF??
??FFFFFFFFServer UPS
--
IC904 93LC66 Most likely, this is a profile for the server for managing group outlets and time delays
(Outlet Group 1) via the NMC card.
Older models provide control of two groups of controlled sockets (Outlet Group 1 & Outlet Group 2).
They can be activated via the control panel or via an NMC card.
The SMT1500RMI2U is equipped with a PCB: 640-3081J-Z-001 1335BSAA15655138 and a relay RY901;(RY902), with the help of which a remote power reset is performed connected equipment.
At the beginning of the dump there is the SN/production date (S361030X7272), device type, model, battery type, outlet group number and timing parameters.
By rearranging the letters, you can match it with the S/N (XS6301032727) that you have on the UPS case.
Remote control of group sockets via LAN/Internet can be similar to the Wake On LAN protocol.
IC8 (LC93LC56) contains the UPS SN and calibration constants of the control controller IC11 (AT89C51RC).
-
IC303 is the reset circuit of the MC34064.
-
Howdy all,
I've done what Fish_bonz has done and that is Purchase another SMT1500i UPS from Ebay from the UK, which was 95 pounds and 88 pounds shipping, add sundry items to the purchase, convert to Australian Dollars and OUCH.
Comes with NO batteries but is guaranteed working and by the looks original box too.
Looking at the serial number of the unit, it'll be an ID18 setup. SO once I have that in hand (About 3 weeks away) I'll be able to disassemble this working unit (After testing) and remove the main Micro controller off of it (AT89C51RC)
Then put a socket on the board for this device. Read the chip, program a new one. test that out in the unit. then if that repairs it then replace the chip on the other UPS and bring it back to life.
Lots of if's and but's and possibilities.
Ahh the joys of electronics, internet searching and lack of information...
-
Just an update of sorts.
UPS from the UK arrived, but it wasn't in an original box but some other thing which was a thin box, the unit had a thin layer of bubble wrap around it and the box was filled with packing peanuts UGH...
The box was not in a good shape and upon inspection the UPS had been dropped and suffered damage to the left rear of the unit.
Using my metal working skills we straightened the bend in the case.
Inserting a new set of batteries that I'd ordered while waiting for the unit to arrive, building the battery pack with connector and fuse (100A) and subsequently powering it up all looked good.
UPS firmware on the sub board was 8.8 and via USB we upgraded that to 15.0 and didn't brick this one
It works fine BUT the display goes blank after several days of use. Inserting network card and checking it's configuration. The display is set to permanently ON. So it does have a fault.
Going through Ebay to resolve this but that's another story.
Anyway, The sub board with it's STM32F103RCT6 ARM processor, needs the right piece of hardware to read that. I've got the software for the reader / programmer from this site...
https://stm32-st-link-utility.software.informer.com/
and subsequently ordered also a STM32 reader/programmer that only costs a small amount from Aliexpress.
the UPS IS ID18 so that's a plus. So once I've got that NEW reader on hand then we will read the contents of the sub boards ARM processor.
This sub board is for some basic interfacing to the main UPS board as when I put the working board into the dead UPS, the alarm didn't go off, the display came to life BUT it couldn't control the UPS as it didn't see it.
So once we get this sub board back to life it looks like we WILL need to pull off the AT89C51RC micro controller from the main board of working UPS. Put a socket on the board and read the data from the controller.
Drop in the other controller from the dead UPS and reprogram that and put a socket on that board too and hopefully we will get them both working again.
I do have 44 pin PLCC sockets on hand as well as 8 AT89C51RC micro controllers that came in the post.
Will update in a while when I've got the DATA from the ARM Processor and micro controller for all to use
Looked into the SMT18UPS_15-0.enc file and discovered the extension means it's encrypted and in all things it's a base 64 encryption, so good luck with that
So yeah we did look into that as well with no joy.
Photo's of the damage...
-
.enc might be anything.
-
it's a base 64 encryption, so good luck with that
So yeah we did look into that as well with no joy.
base64 is just way to transfer binary data over text symbols.
https://en.wikipedia.org/wiki/Base64
there is no key for encryption, you can encode/decode it with any free tool. -
Ahh ok, will look into that further. Thanks flaotte
-
Definitely not base 64!
The tool is java-based, so much easier to reverse engineer.
You can unpack LaunchFUW.exe with 7zip.
Navigate to com\apc\microlink\fwtool.
Open each class files with in Recaf.
There's some interesting stuff:
DESEncrypter.classCode: [Select]public class DESEncrypter
implements IEncrypter {
private static final String kENCPREFIX = "SOELM";
private static final String kENCSUFFIX = "EOELM";
private static final String kKEY = "H25s@ase";
public String doEncrypt(String plainText) throws InvalidKeyException, NoSuchAlgorithmException, InvalidKeySpecException, NoSuchPaddingException, IllegalBlockSizeException, BadPaddingException {
byte[] keyBytes = kKEY.getBytes();
DESKeySpec desKeySpec = new DESKeySpec(keyBytes);
SecretKeyFactory secKeyFactory = SecretKeyFactory.getInstance("DES");
SecretKey key = secKeyFactory.generateSecret(desKeySpec);
Cipher cipher = Cipher.getInstance("DES/ECB/PKCS5Padding");
cipher.init(1, key);
byte[] textBytes = plainText.getBytes();
String encryptedText = kENCPREFIX + this.byteToHexString(cipher.doFinal(textBytes)) + kENCSUFFIX;
return encryptedText;
}
private String byteToHexString(byte[] byteBlock) {
StringBuilder hexString = new StringBuilder();
int i = 0;
while (i < byteBlock.length) {
byte b = byteBlock[i];
String str = Integer.toHexString(b);
if (str.length() > 2) {
str = str.substring(str.length() - 2);
}
if (str.length() < 2) {
str = "0" + str;
}
hexString.append(str);
++i;
}
return hexString.toString().toUpperCase();
}
}
FWToolConstants.classCode: [Select]public static final String kHashPassword = "o9aZNAPyYcxs86ysOpGUdg==";
public static final String kSecretKey = "apcschneider@2021";
UtilType.classCode: [Select]private static int deviceID = 0;
String originalString = "apc@123";
private static SecretKeySpec secretKey;
private static byte[] key;
VerifyFileCompatibility.class
Some stuff going on here, too.
VerifyFileCompatibility$FileHeader.class
Here you can see the firmware file has a 128 byte header, might include a key, keep searching in other class files and you migh find out.
Also there're some details about how to parse the file:Code: [Select]public void parseData(byte[] data) {
this.version = data[0];
this.command = data[1];
byte[] size = new byte[4];
System.arraycopy(data, 6, size, 0, 4);
this.fileSize = this.unsignedBytesToInt(size);
byte[] id = new byte[2];
System.arraycopy(data, 12, id, 0, 2);
this.deviceID = this.unsignedTwoByteArrayToInt(id);
UtilType.setDevideId((int)this.deviceID);
FWToolApp.theLogger.debugMsg("deviceID:" + this.deviceID);
byte[] filecheck = new byte[2];
System.arraycopy(data, 16, filecheck, 0, 2);
this.fileChecksum = this.unsignedTwoByteArrayToInt(filecheck);
this.index = data[18];
this.fwversionStringSize = data[19];
this.fwversionString = this.setValueFromByteArray(data, this.fwversionStringSize, 20);
FWToolApp.theLogger.debugMsg("fw version String:" + this.fwversionString);
this.byte64 = data[64];
byte[] check = new byte[2];
System.arraycopy(data, 126, check, 0, 2);
this.headerChecksum = this.unsignedTwoByteArrayToInt(check);
byte[] xmodemstring = new byte[33];
System.arraycopy(data, 68, xmodemstring, 0, 33);
this.stringToWaitfor = this.setValueFromByteArray(xmodemstring, 33, 0);
if (this.stringToWaitfor.equals(Messages.getString((String)"VerifyFileCompatibility.45"))) {
this.stringToWaitfor = null;
}
}
Also: calculatefilechecksum, calculateheaderchecksum.