-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which MCU model is supported? #6
Comments
Definitely CB series with more flash memory.
Yes, pinout doesn't really matter from firmware side.
Both types with and without CRC are supported. The firmware detects automatically if CRC is required.
That's purely a hardware question. For the existing bms-15s80-sc board it must be 3.3V.
Yes. Not by myself, but by @thomasplaz. For any new hardware design I would recommend to choose an MCU with more RAM and flash, which will make firmware upgrades via CAN and other things much easier. Either STM32G0 series or STM32F091. |
Many many thanks for quick reply. I will consider more powerfull MCU but i am not familiar with Zephyr OS.(I will study it.) Is it easy to implement another STM MCU to existing bms firmware? If so, do you have any resources (links-videos-pdf etc.) so i can educate myself on firmware? |
Yes, that's one of the main advantages of Zephyr. Basically you just need to add another board specification to the Some links: |
Many thanks for links.I will study them. I decided to use STM32F091CCT6. I will make a pull request if i will able to port this mcu to your firmware. Another question regarding precharge mosfet on Switch-N-Sense . In BQ76930 datasheet precharge mosfet source pin is connected to BAT+( Battery most positive terminal) as shown below: But in switch n sense it is connected to LOAD+ side. I couldn't understand why? Could you please explain? |
The path is to precharge the bus, not the battery. This is sometimes also called pre-discharge. See also here: https://learn.libre.solar/system/bms.html#bus-precharge |
Hi again For those people are reading this on future and considering building a custom BMS: While waiting to shipping and PCB manufacturing process i decided to exercise with porting bms firmware, read many documents related to porting thanks for links, many things to learn.
As you suggested RAM and FLASH usages are high. As i said before i wanted to test firmware on STM and try to learn porting it thats when i got some problems.
My ST-LINKv2 was not cooperating with me because it's a clone. 🤕 I had to change stlink.cfg in Zephyr-sdk and add " set CPUTAPID 0x2ba01477" line on it to fix it. It fixed my problem. This file is located on "zephyr-sdk-0.16.3/sysroots/x86_64-pokysdk-linux/usr/share/openocd/scripts/interface/stlink.cfg" Then Cpu not halted problem.
I fixed it by editing openocd.cfg file to "reset_config srst_only" to "reset_config none". This file is located on "west-workspace/bms-firmware/boards/arm/'yourboard'/support/openocd.cfg"
As you might see on output i have stm32f4x. I have a non-name development board (bought from aliexpress) that i have lying around which is based on STM32F405RGT6. I choose this because it is identical with "adafruit_feather_stm32f405" Zephyr_Adafruit which is supported by Zephyr OS. There is nothing spesific about this MCU, i just wanted to play with firmware and learn something new. My development board looks like this: I hooked up wires like this: USART3 TX TO PB10 Y9 STLINK SWCLK PA14 P4 (Y9-Y10-P4-P5 and RST are STM405dev board PCB markings) Anyway i tried to port it from adafruit feather and modified devicetree, yaml, defconfig and board files. Here is my custom board folder archive: I really don't know what was gone wrong but my CPU is halting. Here is serial console output about BUS FAULT:
I have read many forums about this issue try to figure out whats going on. Someone suggested to add two lines
to project.conf file. I created "west-workspace/bms-firmware/app/boards/bms_f405.conf" file and compiled firmware again and not i am getting another error which is:
Now i am stuck at MPU FAULT error which i am not sure how to fix this. Could you point me to the right direction? Hope this post helps newbies like me on Zephyr. Another question about building firmware (this may be stupid to ask but i am newbie at Zephyr) when i run
and change some values about MCU or something it saves .config file but when i command Many thanks. |
I assembled my board and uploaded firmware for F072. Soldering went fine and nothing blow up. For testing i soldered 220ohm resistors instead of cells to use as a voltage divider to test BMS. In here which you ancountered same bug as me before, i couldn't figure out how to fix that so i decided to update firmware with "main" branch with v23.1 tag which i assumed problem was fixed. But now it fails when updating new values from AFE. At first boot i get 0.000 values then when BMS updates AFE data it gives "Balloc succeeded" error again. I cannot see thingset mLive data on both firmwares. When i power up only MCU without powering on AFE i can see 0.0000 values.Here is my mLive settings on menuconfig: If i disable "Enable regular reporting of live metrics by default" on menuconfig MCU keeps working without halting CPU. Another issue i have is about precharge mosfet.The only change is from your schematic is i used 2x NCEP6090AGU mosfets instead of 4x FDMT80080DC. When i connect BAT+ and BAT- to my power supply (which is 40Volts) precharge P mosfet starts to conduct and i have output on load side even without powering on BMS. I had to desolder pfet (ZXMP10A13F) to get normal output on load side. I soldered 4.4k resistor in series with a green led to monitor load output. When pfet removed i measured pads drain have 39v gate have 39v and source is 0v in regerence with BAT-. Which seems true for Pfet working principle. Could you point me the right direction? |
1) Ok i think i figured out "Balloc succeeded" error. You have to add these 3 lines to your prj.conf file as below: (I'm not sure if it is right way yo fix it but now it works.) Then compile firmware again. "Balloc succeeded" error will be gone and BMS will output Thingset battery parameters as expected. Make sure in dts file thingsetserial is configured as right uart port. I used both zephyr console and thingset console in uart3. 2) Another issue was misreading voltage on Cell 6, Cell 7 and Cell 8.(Top battery group) I know it should be fixed on "Rev2" design in here with seperation on C5.1 and C5 lines and my design is based on "Rev2" but when i checked bq76930 datasheet it shows that C5.1 and C5 should be shorted. Here is a screenshot for C5.1 and C5 seperated: And here is C5.1 and C5 are shorted together on PCB: Notice that top row shows accurate voltages in my case. Voltages seems ok but notice that Cell 1 and Cell 10 Voltages are a little bit off. This was caused by internal power supply current drain i believe so i added 100ohm resistor to BAT and rerouted PWR. Notice that BAT+ is directly connected to cell. If you feed internal power supply from BAT pin it will reduce voltages while AFE reads from VC10. Here is summary "fix": Battery should connected BAT+ and BAT- separately from balance connections such as C0-C1-C2-C3...C9-C10 etc. 3) Ok from now on it seems we "fixed" voltage misreadings but even we do not draw any current from power supply AFE thinks that we are drawing 0.37 Amps from BMS: And it shows 0.04 Amps as expected: I didn't load BMS yet but further tests will come, I will share results and my findings. Precharge issue still needs to be addressed. @thomasplaz I am just wondering did you encounter same problems like me? |
That fix looks OK. All these issues with different libc versions should be gone in the future, as Zephyr has now switched to picolibc as the default. Before that, the newlib-nano was not supported for ESP32 MCUs, so we had to use the full libc. We can switch to picolibc for all boards when we update to Zephyr v3.5.
Cannot say much regarding this issue at the moment, as I have never used the updated design by @thomasplaz myself because I moved to the bq76952 for new designs.
Great that you were able to fix this and thanks for posting the update.
No, not at all. I'm very happy that you are building the board and posting your progress. I was just very busy in the past weeks and didn't find time to answer. I wanted to double-check the precharge issues you identified with my board before answering. Did you compare the circuit with the one in the new BMS C1? For that one I'm very sure that the bus precharge works, as I have tested it not too long ago. As a general remark: Please feel free to open separate issues for separate things. It will help to maintain the overview. And some of the issues above are clearly related to firmware and not the board hardware, so they would ideally be discussed in the firmware repo. |
Hi Retro Fitt, You can find the detailed instructions for building the BMS at Maybe you can translate the pages using google translate. After setting up the hardware of the BMS, we found the following issues: • Connection of the CAN microcontroller pin “CAN_STB” on the BQ76940 is faulty • The connection of cells 5/6 and 10/11 is wired in such a way that a voltage measurement with mutual interaction takes place For our 15 cell battery, we have put an updated hardware (first) variant on github, which works in our setup. The BMS board also has additional mounting holes. The cell voltage measurement works without any problems with the changed layout. We do NOT use the SNS board and have integrated the power electronics onto our main board, which was specially designed for the storage: In a second variant, the BMS board and the SNS board are combined on one board in Eagle. These files are linked at We use mbed-based software for programming the bq769x0 because it was well suited to our purposes and we were reluctant to switch to Zephir (due to time constraints). We have now adjusted the software so that the SOC is also calculated correctly. Can be found at: The new SOC calculation is not online yet, coming soon, if you need it immediately please let me know.. |
@martinjaeger
I no longer have any hardware issues but i might have software issues which i will make new issue on firmware repo. |
Ok, thanks for the heads up. Hope you are fine again. Should we close this issue? |
Very nice project. I am designing a custom BMS based (bq76930 10s) on your work. Thank you very much for such work.
I have a couple of questions:
Is STM32F072RBT6 (64 pin version) compatible with your bms firmware?
Is CRC mandatory to commucate with MCU? CRC or without CRC which one is compatible with your bms firmware?
Is LDO voltage relevant? Which is prefered?2.5 or 3.3?
Is "rev2" branch hw design tested?
Thanks
The text was updated successfully, but these errors were encountered: