diy solar

diy solar

Daly BMS Faulty - Depotted and diagnosed

gnif

New Member
Joined
Apr 27, 2023
Messages
19
Location
Australia
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 verified before connecting the BMS as per the instructions (this is proven later too as the exact failure was discovered).

So why did I risk a tear down? There was shipping damage to my battery cells from China to Aus and as it took so long to get them replaced, by the time I could test the BMS it was out of warranty.

Things I tried were:
* power the bluetooth module directly with 3.3V
* Connect to the UART directly with a TTL adaptor, which when I did, caused the adaptor to fail to be recognised by the PC. The 3.3V output of the adaptor was being pulled down to around 2V indicating the adaptor I was using could not supply enough current.

So I reconnected the BMS to the battery pack and noted that the 3.3V pin on the UART connector was pulsing on for a few us at a time on a DSO, this is a good indication of a LDO regulator going into overload protection (possible shorted rail). It was time to dig deeper.

After watching another person attempt this on Youtube and seeing him tear parts off the PCB I decided to use some hot air to soften the potting compound and was able to remove it without any damage. Took about an hour to fully depot the device.

Interesting things of note on inspection:

* There is a LED on the PCB (kind of pointless when it's potted)
* The MCU is a GD32E230C8T6 (STM32 like device, similar to the F1 series, very nearly pin compatible but register base addresses are different)
* There are four pads on the PCB near the MCU that look like they might be a debugging UART is the STLink Serial Wire Debug (see post #6 for pinout)
* There are footprints for several additional connectors on the opposite side marked "KEY", "DIO", and "SW"
* It seems the number of cells the BMS is designed for can be adjusted by moving the zero ohm resistor (or adding more) on the back near the sense connector at the edge of the PCB. S16 seems to be the highest number before additional parts are needed on the PCB, but it could be possible to turn this into anything less simply by moving/adding shorts there to reconfigure it.

General things of note:

* No physical damage
* No burn/brown marks or the distinct burning electronics smell.
* No shorted or open mosfets

So the first hint I had was the 3.3V pin going into what looked like a fault, as such checking for a short on the 3.3V rail was the first thing to do. Between that pin and ground there was no short, however there is a 3.3V SOT32 LDO on the PCB that is to provide power the GD32E230. Checking this regulator showed a short between it's output and ground and removing this regulator did not remove the short.

So I removed the MCU with hot air (more potting compound oozed out from under the chip when I did this) and again tested for a short... and it was gone. Now when connecting the USB UART TTL adaptor, it works as expected. Checking the VSS and VDD pins on the MCU IC itself reads a dead short.

So, the MCU had failed from factory. Thankfully this device is VERY similar to the STM32 family which I am intimately familiar with (I am the original author of stm32flash) and I found someone has posted a firmware upgrade file for their BMS which is just in standard intel hex format. As such I have ordered a replacement MCU and will attempt to repair this device when it arrives.

Attached images of the device after removing the MCU and noting the 3.3V rail is no longer shorting, resulting in the LED lighting up when the UART is connected.
 

Attachments

  • 1682658867423.png
    1682658867423.png
    1.9 MB · Views: 91
  • 1682658892012.png
    1682658892012.png
    1.2 MB · Views: 98
  • 1682658907759.png
    1682658907759.png
    1.8 MB · Views: 92
  • 1682658916065.png
    1682658916065.png
    1.3 MB · Views: 100
Last edited:
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.
 
The number of accounts of DALY BMS failing are disturbingly high.
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 ICs like the MCU. The fact that it's even under the MCU and in the vias as evidenced when heated it oozes out, it had to be injected with considerably high pressure while very fluid (so very hot).
 
Cool post.

The number of accounts of DALY BMS failing are disturbingly high.
Exactly why I replaced all my old ones with JK.

If the Daly didn’t outright fail they would kinda sorta work.
They would work intermittently the quit then work.
It was disconcerting so I just replaced the few I had.

No issues from the JK so far.
 
Last edited:
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 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 the latest BOOT and update here for STM32 based devices. The BOOT version is `V1.01.1Z` and the upgrade firmware is `BMS-ST103-309E11_230324_001T`
 

Attachments

  • 2023-04-29-STM32F103.zip
    86.4 KB · Views: 38
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
 

Attachments

  • 2023-04-29-GD32E230.zip
    59 KB · Views: 40
Keep us updated on any progress with this.
I had a 4s one with similar issues.
 
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, simply powers up the DC/DC converter to generate the 3.3V rail that powers the MCU. Even if the battery is not present, holding the pin low will prevent the MCU from shutting down.

2) The 3.3V output for the Bluetooth is software controlled, GPIOB pin 9 is responsible for this and is configured as open drain. Clearing this pin will enable the output. This explains why people have issues with the Bluetooth being unreliable, the MCU is shutting it's power off.

3) The sh367309 is not using the MCUs I2C perhiperal for whatever reason... DALY have decided to bit-bang the protocol. SDA is on GPIOB_15 and SCL is on GPIOB_14.

4) The sh367309 is responsible for enabling the battery, over current detection, balancing, etc... pretty much everything. The MCU is responsible for configuring the device and providing feedback via UART, etc.

Not sure if I will continue this at this point in time, however it's a start and enough to fully implement a custom firmware for this DALY BMS. It would be possible to repurposed the display connector IO for other things, like driving a Hitachi LCD display. It is even possible to disable the built in balancing and instead set a GPIO pin to enable an external active balancer.

Note: Already got some basic code working that can communicate with the SH367309.
 
Cool stuff! I don't have a Daly BMS but enjoy this type of project. I guess the biggest question is whether you can implement meaningful features that the factory software doesn't support. I haven't looked at the SH367309: does it allow you to get any info about individual cells? If so, you could provide per-cell stats, which would be useful when wanting to fix a pack with a dead cell... (Just idle thoughts)
 
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, simply powers up the DC/DC converter to generate the 3.3V rail that powers the MCU. Even if the battery is not present, holding the pin low will prevent the MCU from shutting down.

2) The 3.3V output for the Bluetooth is software controlled, GPIOB pin 9 is responsible for this and is configured as open drain. Clearing this pin will enable the output. This explains why people have issues with the Bluetooth being unreliable, the MCU is shutting it's power off.

3) The sh367309 is not using the MCUs I2C perhiperal for whatever reason... DALY have decided to bit-bang the protocol. SDA is on GPIOB_15 and SCL is on GPIOB_14.

4) The sh367309 is responsible for enabling the battery, over current detection, balancing, etc... pretty much everything. The MCU is responsible for configuring the device and providing feedback via UART, etc.

Not sure if I will continue this at this point in time, however it's a start and enough to fully implement a custom firmware for this DALY BMS. It would be possible to repurposed the display connector IO for other things, like driving a Hitachi LCD display. It is even possible to disable the built in balancing and instead set a GPIO pin to enable an external active balancer.

Note: Already got some basic code working that can communicate with the SH367309.
Great work on this man, appreciate your efforts.

This sounds exactly what happened to mine. I supplied 3.3v from cell 1 to the bt dongle and the bt worked again. I was still able to access via the sinowealth sw.

Would a firmware re-flash via pc fix this issue do you think?20210821_101145.jpg
 
Last edited:
Would a firmware re-flash via pc fix this issue do you think?
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 advocate, if this does become a thing expect the sources to be released to the general public.

Kudos for doing that properly btw and popping the pin out, every other person I have seen do this cuts the wire.
 
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 = GPIOA 9
8 = GPIOA 8

It's baffling to see the EEPROM on the I2C peripheral but the SH367309 is bit-banged. I2C is a bus that supports multiple devices, they could have literally connected both to the same bus and done away with the bit-bang mess and taken full advantage of the I2C hardware in the MCU.
 
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 and a mosfet to the `VPRO` pin on the `SH367309`. By configuring the pin as open drain and pulling it low, the `SH367309` exits programming mode (which disables access to the EEPROM for both read & write) and begins to operate.

I am now able to actually read the results now of the ADC for each cell's voltage, and I assume much more now also. Next thing I need to do is get a neat method of wiring this back up to the battery so that I can test it with some real data. I would like to get it to a point where I can feed the cell voltages into a InfluxDB and use Grafana to plot the cell voltages over time.
 
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.
Much appreciated if you could post the datasheet, I've been looking for it
 
Back
Top