Switched ADC BMS

[Leo M]

Yes I will work on the software again, currently focusing on ccs.


What's the purpose of this sentence? Another translater bug?

Ok maybe leave a quick note if text is translated so it's not taken too literal

I wrote that it is probably not difficult to save my Can cards in the new firmware version.This is a useful option for everyone)))

[Jacobsmess]

Hey Johu,
any recommendations on a suitable wire-to-board connector for the 17pincell tap connection?
I've looked on JLCPCB and LCSC but neither seem to have something suitable to my inexperienced eyes. what is the max voltage rating required? do they need to be 400V rated or not?
failing a wire-to-board connection, what is the recommended alternative? I'm going to get JLCPCB to solder the boards up completely rather than mess up the boards with my sloppy soldering!
thanks

[johu]

The max voltage per board is about 70V so I don't think that is any constraint. I used some sort of Molex connector. Couldn't really find that at JLC but there should be some sort 0.1 inch available.
I don't recommend wire-to-board because you don't want 17 live wires dangling about when disconnected

[Jacobsmess]

The max voltage per board is about 70V so I don't think that is any constraint. I used some sort of Molex connector. Couldn't really find that at JLC but there should be some sort 0.1 inch available.
I don't recommend wire-to-board because you don't want 17 live wires dangling about when disconnected

Ok I may have misunderstood what wire to board is, I was thinking it would be a connector from the battery harness to the PCB. Yes I'm struggling to find something for the 17 pin option on JLC but will look at molex options.

[johu]

I wrote that it is probably not difficult to save my Can cards in the new firmware version.This is a useful option for everyone

Check it out: https://github.com/jsphuebner/FlyingAdc ... 330e883082

There is now separate maps for internal and external use. That way you can map your own messages without disturbing operation. Of course the already used CAN Ids mustn't be reused in the user map.

[MLL]

Check it out: https://github.com/jsphuebner/FlyingAdc ... 330e883082

There is now separate maps for internal and external use. That way you can map your own messages without disturbing operation. Of course the already used CAN Ids mustn't be reused in the user map.

and when will there be a release?

[johu]

Dont we love it when the reaction to an announcement is yet another request You're welcome...

I've added a workflow that builds binaries on every commit https://github.com/jsphuebner/FlyingAdcBms/actions

[MLL]

Dont we love it when the reaction to an announcement is yet another request You're welcome...

I've added a workflow that builds binaries on every commit https://github.com/jsphuebner/FlyingAdcBms/actions

I see you have made additional can cards after all, it's very cool. Will there be bin, hex files? Otherwise, there is no lunix at hand for checking now

[uhi22]

The plan is, that the bin and hex files are available at the link https://github.com/jsphuebner/FlyingAdcBms/actions
How does this work? Johu configured a "continuous integration job" to the github. This job automatically builds the software and stores the results. Each run is listed on the linked page, the most recent is on top of the list. Selecting the intended job and scrolling down the page to the chapter "Artifacts", there are the zipped bin and hex files.

[Leo M]

Отлично! Спасибо Ёханес!

[Jacobsmess]

Ah! I finally went to order my BMS boards from JLC and the L1 4.7uH Inductor_SMD:L_1210_3225 CBC3225T4R7MR C90319 is out of stock
Is this a suitable alternative?
https://www.lcsc.com/product-detail/spa ... 91924.html

[johu]

Sorry, missed that. I assume you got it sorted... Inductors are quite often out of stock.

Anyway, a bit of an update.
I have changed the addressing scheme slightly so that sdobase and pdobase only need to be set on the first module and it passes them on to the sub modules. I assume most people don't need to touch this but in case you need to it is now easier.

I also changed the ID of the main control message to pdobase and all subsequent ones to pdobase+1 +2 and so on.

sdobase now defaults to 10 to leave room for other OI equipment in the lower range.

I have also integrated the 3-step CC/CV charging curve that I stole from VW. This is safer than deducting charge power from the current SoC as that can be skewed.

And finally I also integrated the SoH estimation from stm32-car but with the potential improvement to adjust it over time. So if you leave the BMS on permanent 12V power it preserves the SoH in its buffered SRAM and IIR-filters new estimations on it. So estimation errors should even out. The value isn't used in any calculation yet but it can help you adjusting nomcap to the actual battery capacity.

[Jacobsmess]

Sorry, missed that. I assume you got it sorted...

Well, I did but hadn't gotten around to order following trying for a long time to find the perfect header of which I couldn't find anything that would provide a direct connection from the PCB to and external connector. Anyway, I was going to just use a normal header but the 5V DCDC is now out of stock
I'll wait a little longer then....

[Jacobsmess]

Is there a pinout somewhere for the J5 connector? I'm assuming this is what I need to connect my STLink to to flash the bootloader and firmware. Pins are labelled VDCG, would that be
V = 3.3V
D = SWDIO
C = SWCLK
G = GND
? thanks

[johu]

Correct!

[Jacobsmess]

So partially as a reminder of what I've done so far, a how-to (or possibly how not to!) and partially as a cry for help I'm writiing what I've done so far in order to flash my BMS boards.

1 - purchased an STLink USB dongle, connected it up to the BMS board using J5 pinout as...
V = 3.3V
D = SWDIO
C = SWCLK
G = GND

2 - flashed the bootloader linked from the github here https://github.com/jsphuebner/FlyingAdcBms using STLink GUI on Linux to the default address that comes up... 0x08000000
"The firmware is linked to leave the 4 kb of flash unused. Those 4 kb are reserved for the bootloader that you can find here: https://github.com/jsphuebner/tumanako- ... bootloader When flashing your device for the first time you must first flash that bootloader. After that you can use the ESP8266 module and its web interface to upload your actual application firmware. The web interface is here: https://github.com/jsphuebner/esp8266-web-interface Binaries are here: https://github.com/jsphuebner/FlyingAdcBms/actions"

3 - installed the web interface on an ESP32 board (Lilygo TCan with onboard CAN) using PlatformIO (because for some gawd-damn reason I can't get the ESP32 SPIFFS data upload to work in Arduino IDE anymore).

4 - connected the ESP32 to the BMS board via CAN (H/L and GND) and gave the BMS 12V, Gnd and 12V on the enable, and gave the ESP32 12V and GND

5 - Connected to the web interface wifi network and go to 192.168.4.1, here I get "Communication problem between ESP and STM" which I assume is because I've not flashed the firmware yet.

6 - get the BIN from https://github.com/jsphuebner/FlyingAdcBms/actions (don't forget to log in if you want to actually download the files!)

7 - flashed the BIN on the WEB UI using the firmware upload, I get a pretty much instantanesous "upload successful message", but then it hangs...

8 - power cycle the boards

9 - ??? still get the communication error so I suspect it's failed.

Any help/nudging/guidance appreciated.

[johu]

Yes unfortunately the ESP doesn't play well when there is no firmware installed. It doesn't pick up the cyclic "Hello" from the boot loader. So flash the firmware HEX file with your ST Link as well.

[Jacobsmess]

So flash the firmware HEX file with your ST Link as well.

Hmm I think I actually tried this subsequently and got a "binary overwrites flash" error. Do I write to the same address as previously? (0x08000000) And still have the "communication problem between esp and STM" warning.

[johu]

You don't specify addresses when using hex files as they contain the address info already

[Jacobsmess]

So I've resorted to the cmd line tool for a bit more information on what's going on.
Here's the output...
~$ sudo st-flash write stm32_loader.hex 0x08000000
st-flash 1.6.0
2024-07-21T08:09:24 INFO usb.c: -- exit_dfu_mode
2024-07-21T08:09:24 INFO common.c: Loading device parameters....
2024-07-21T08:09:24 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2024-07-21T08:09:24 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2024-07-21T08:09:24 INFO common.c: Attempting to write 8008 (0x1f48) bytes to stm32 address: 134217728 (0x8000000)
Flash page at addr: 0x08001c00 erased
2024-07-21T08:09:24 INFO common.c: Finished erasing 8 pages of 1024 (0x400) bytes
2024-07-21T08:09:24 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL core id
2024-07-21T08:09:24 INFO flash_loader.c: Successfully loaded flash loader in sram
8/8 pages written
2024-07-21T08:09:24 INFO common.c: Starting verification of write complete
2024-07-21T08:09:24 ERROR common.c: Verification of flash failed at offset: 0
stlink_fwrite_flash() == -1

~$ sudo st-flash write stm32_bms.hex 0x08000000
st-flash 1.6.0
2024-07-21T08:10:35 INFO common.c: Loading device parameters....
2024-07-21T08:10:35 INFO common.c: Device connected is: F1 Medium-density device, id 0x20036410
2024-07-21T08:10:35 INFO common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2024-07-21T08:10:35 INFO common.c: Attempting to write 68964 (0x10d64) bytes to stm32 address: 134217728 (0x8000000)
2024-07-21T08:10:35 ERROR common.c: addr too high
stlink_fwrite_flash() == -1

[johu]

Please omit the address!

But the actual cause of the error seems to be the binary size. It is 68k but should be more like 25k. How did you obtain it?

You can get prebuilt bin/hex here: https://github.com/jsphuebner/FlyingAdc ... 9399397611

[Jacobsmess]

I will double check but the hex files I flashed (and binaries I tried) all came from the latest "actions" on the GitHub.

[johu]

Ok then maybe the utility tries to flash the hex file as a binary blob. It probably needs a command line switch to treat it as hex

[Jacobsmess]

Ok then maybe the utility tries to flash the hex file as a binary blob. It probably needs a command line switch to treat it as hex

Yes it turns out if it's default assumption is the file is a binary, you need to state its a hex.
So I flashed the bootloader hex.

st-flash --format=ihex write 'stm32_loader.hex'
st-flash 1.7.0
2024-07-23T19:09:29 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
2024-07-23T19:09:29 INFO common.c: Attempting to write 2828 (0xb0c) bytes to stm32 address: 134217728 (0x8000000)
2024-07-23T19:09:29 INFO common.c: Flash page at addr: 0x08000000 erased
2024-07-23T19:09:29 INFO common.c: Flash page at addr: 0x08000400 erased
2024-07-23T19:09:29 INFO common.c: Flash page at addr: 0x08000800 erased
2024-07-23T19:09:29 INFO common.c: Finished erasing 3 pages of 1024 (0x400) bytes
2024-07-23T19:09:29 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
2024-07-23T19:09:29 INFO flash_loader.c: Successfully loaded flash loader in sram
2024-07-23T19:09:29 INFO flash_loader.c: Clear DFSR
3/ 3 pages written
2024-07-23T19:09:29 INFO common.c: Starting verification of write complete
2024-07-23T19:09:29 INFO common.c: Flash written and verified! jolly good!

And then the BMS firmware

st-flash --format=ihex write 'stm32_bms.hex'
st-flash 1.7.0
2024-07-23T19:09:58 INFO common.c: F1xx Medium-density: 20 KiB SRAM, 64 KiB flash in at least 1 KiB pages.
2024-07-23T19:09:58 INFO common.c: Attempting to write 24492 (0x5fac) bytes to stm32 address: 134221824 (0x8001000)
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08001000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08001400 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08001800 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08001c00 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08002000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08002400 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08002800 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08002c00 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08003000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08003400 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08003800 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08003c00 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08004000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08004400 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08004800 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08004c00 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08005000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08005400 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08005800 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08005c00 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08006000 erased
2024-07-23T19:09:58 INFO common.c: Flash page at addr: 0x08006400 erased
2024-07-23T19:09:59 INFO common.c: Flash page at addr: 0x08006800 erased
2024-07-23T19:09:59 INFO common.c: Flash page at addr: 0x08006c00 erased
2024-07-23T19:09:59 INFO common.c: Finished erasing 24 pages of 1024 (0x400) bytes
2024-07-23T19:09:59 INFO common.c: Starting Flash write for VL/F0/F3/F1_XL
2024-07-23T19:09:59 INFO flash_loader.c: Successfully loaded flash loader in sram
2024-07-23T19:09:59 INFO flash_loader.c: Clear DFSR
24/ 24 pages written
2024-07-23T19:10:00 INFO common.c: Starting verification of write complete
2024-07-23T19:10:00 INFO common.c: Flash written and verified! jolly good!

All looking good and I get a little red LED, which I haven't seen thus far, although only after flashing the firmware whilst the STLink V2 is connected, it no longer shows when connected to 12V, and upon disconnecting the STLINK V2 and reconnecting it no longer shows.

Connecting the BMS board to 12V, GND, 12V to enable, CANH and CANL, connecting to the wifi, and navigating to 192.168.4.1 I get the Web interface, no longer do I have the communication error (which may have been down to an error in the OI_Can.cpp pin mapping), I get firmware: null.

[johu]

It seems the esp32 firmware isn't up to date. Is it the latest github source?