Most reacted posts

Hi All, First post here after a few days of using these forums to try to discover why my Daly BMS would not activate. Before I start I should state that I do hobby electrical engineering and have enough experience to say with certainty that I did not damage the BMS. All wiring was correct and...

Today I got the GD32E230C8T6 and successfully replaced the part, flashed it, and brought the BMS back from the dead. This allowed me to finally do some sniffing of the I2C bus and figure out what I was missing in my implementation. So another discovery, GPIOB pin 9 is connected via a transistor...

I have been in communicaiton with DALY over this issue and have convinced them to not only provide the latest firmware, but also the BOOT firmware for the STM32F103RBT6. I am hoping to also obtain the GD32E230C8T6 firmware as this is more useful to me in recovering this device. I have attached...

Ok, some more progress.. designed a breakout PCB so I can easily disconnect/connect the BMS from my battery and wrote some code to dump out the ADC cell voltages, and had a few problems. 1. Was getting cells 1-6 just fine, but 7, 8 & 9 gave very odd values. This turned out to be an electrical...

Amazing service from DALY on this honestly, they are providing me with the firmware and files to repair my device that normally one wouldn't be able to obtain. Here are the latest files for the GD32E230C8T Boot version is: V3.01.1Z Firmware version: BMS-GD230-309E31_230325_001T

Some more progress... Last night I managed to figure out the last few issues that were preventing the device from connecting the battery. I can and have now set under and over voltage thresholds and the device is operating correctly. Some more interesting things to experiment with though. 1)...

The potting compound might be to blame, it's injection moulded and as such it has to be molten. I didn't test the exact temperature needed to melt it, but with my iron set to 250C it was able to flow without burning. The thermal cycling at these high temperatures might damage the more sensitive...

Found some more time today to work on this. Still waiting on parts, but curiosity got the better of me and I have started writing firmware for this device. So a few things I have discovered. 1) The trigger button on the Bluetooth module which simply grounds out pin 3 on the UART connector...

I doubt it, either the mosfet that controls the 3.3v out has failed, or the firmware is just crap. I personally feel the latter is the more likely scenario. If I decide to pursue custom firmware (likely at this point) it shouldn't be a stretch to port it to the other models. Note I am a FOSS...

Confirmed that the 2nd device (SH367309) on the BMS can run standalone once configured, your MCU has died. I found and have attached the English datasheet for it if you want to try to interface to it directly via I2C.

Another update, more pins traced UART RX = GPIOA 2 (STM32 UART2 RX) UART TX = GPIOA 3 (STM32 UART2 TX) 24C128 EEPROM SCL = GPIOB 10 24C128 EEPROM SDA = GPIOB 11 8 Pin connector: 0 = GND 1 = 3.3V 2 = VBAT? not sure yet 3 = Trigger (same as pin 3 on UART) 4 = GPIOB 1 5 = GPIOB 6 6 = GPIOB 7 7 =...

Will do, just waiting on my order of MCUs, expected later this month. Love your profile pic btw, you're clearly a fellow aussie :)

https://diysolarforum.com/threads/i-am-not-getting-voltage-on-15v-and-3-3v-pin-of-daily-bms-uart-port.43478/post-769710

Yes, individual voltages

Hate to say it but it's likely the MCU has completely failed and the other IC is still managing the cells based on it's last programmed configuration. I have worked with GigaDevice STM32 clones in the past and have had them just randomly fail like this, not exactly a quality part. You might be...

I have been digging further and the balancing and charge controller function is all handled by the other IC there (SH367309) which I have found the full english datasheet for. I am tempted to just put a STM32F103C8T on there, lift the two pins that are different, and write my own firmware.

An update to this, the four pads near the GD MCU are Serial Wire Debug, from bottom to top in the photo they are: SWDIO (Square pad) GND SWCLK VCC (3.3V)

I am disassembling the protocol from the firmware for this and it seems on the firmware I have a checksum has been implemented. The format I have so far discovered is: Byte 0 = Header, must always be 0xA5 Byte 1 = Unknown still (valid values are 0x40 and 0x80) Byte 2 = Command Byte 3 = Must...

Sorry no idea as my device is currently inoperable. I am waiting on parts to repair it.