Skip to content
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

Closed
Retro-Fitt opened this issue Oct 6, 2023 · 13 comments
Closed

Which MCU model is supported? #6

Retro-Fitt opened this issue Oct 6, 2023 · 13 comments

Comments

@Retro-Fitt
Copy link

Retro-Fitt commented Oct 6, 2023

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 MCU STM32F072CB or STM32F072C8 series?

image

  • 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?

image

  • Is LDO voltage relevant? Which is prefered?2.5 or 3.3?

  • Is "rev2" branch hw design tested?

Thanks

@martinjaeger
Copy link
Member

  • Is MCU STM32F072CB or STM32F072C8 series?

Definitely CB series with more flash memory.

  • Is STM32F072RBT6 (64 pin version) compatible with your bms firmware?

Yes, pinout doesn't really matter from firmware side.

  • Is CRC mandatory to commucate with MCU? CRC or without CRC which one is compatible with your bms firmware?

Both types with and without CRC are supported. The firmware detects automatically if CRC is required.

  • Is LDO voltage relevant? Which is prefered?2.5 or 3.3?

That's purely a hardware question. For the existing bms-15s80-sc board it must be 3.3V.

  • Is "rev2" branch hw design tested?

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.

@Retro-Fitt
Copy link
Author

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?

@martinjaeger
Copy link
Member

Yes, that's one of the main advantages of Zephyr. Basically you just need to add another board specification to the boards/ folder. If you stay within STM32 MCU lines, you can take an existing board and most probably need to change just a few lines in the devicetree.

Some links:
https://blog.golioth.io/how-to-add-a-custom-board-definition-to-a-zephyr-application/
https://docs.zephyrproject.org/latest/hardware/porting/board_porting.html

@Retro-Fitt
Copy link
Author

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:
image
Which is logical i assume.

But in switch n sense it is connected to LOAD+ side.
image

I couldn't understand why? Could you please explain?

@martinjaeger
Copy link
Member

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

@Retro-Fitt
Copy link
Author

Retro-Fitt commented Oct 25, 2023

Hi again
I completed my hardware design, bought parts for it and ordered PCB.


For those people are reading this on future and considering building a custom BMS:
In my hardware design i combined bms-15s80 with switch and sense and made a prototype for lower power requirements. (Normal operation 15A, Short Circuit operation 30A, Overcurrent operation 20A) I didn't finalized it yet it's just prototype to test things out and how they fit to real world. My power need is about 250W in total. I didn't decided cell counts yet and put some solder jumpers on PCB.
image
image
Cost of 5 PCB is about 2 USD without shipping. I included LCSC part numbers on my schematic to order parts easily. All parts cost 10.44 USD as date without shipping per board so in total 10.84 USD which seems very reasonable for such capable BMS of course you have to assemble parts by hand and shipping costs should be considired. The board has 2 layers with two power mosfet's. I will test hardware and fork from martin's original work. Here is BOM file "for all those playing at home":
bom.csv


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.
I actually decided to use STM32F091CCT6 (256KB FLASH and 32KB RAM) instead of STM32F072RBT6 (128KB FLASH and 16KB RAM) but due to no stock available on LCSC i had to buy F072RBT6 for testing. I compiled original firmware without any errors.

$ west build -b [email protected] --pristine
.....
.....
.....
[175/175] Linking CXX executable zephyr/zephyr.elf
Memory region         Used Size  Region Size  %age Used
           FLASH:      103732 B       128 KB     79.14%
            SRAM:       14280 B        16 KB     87.16%
        IDT_LIST:          0 GB         2 KB      0.00%

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.

$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/jigsaw/west-workspace/bms-firmware/app/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.11.0+dev-00726-ge2b6f5655 (2023-09-22-14:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 1000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.150968
Warn : UNEXPECTED idcode: 0x2ba01477
Error: expected 1 of 1: 0x0bb11477

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.

$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/jigsaw/west-workspace/bms-firmware/app/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.11.0+dev-00726-ge2b6f5655 (2023-09-22-14:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.143226
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f4x.cpu       hla_target little stm32f4x.cpu       running

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Error: timed out while waiting for target halted
TARGET: stm32f4x.cpu - Not halted

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"

$ west flash
-- west flash: rebuilding
ninja: no work to do.
-- west flash: using runner openocd
-- runners.openocd: Flashing file: /home/jigsaw/west-workspace/bms-firmware/app/build/zephyr/zephyr.hex
Open On-Chip Debugger 0.11.0+dev-00726-ge2b6f5655 (2023-09-22-14:29)
Licensed under GNU GPL v2
For bug reports, read
	http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
Info : clock speed 2000 kHz
Info : STLINK V2J29S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.143226
Info : [stm32f4x.cpu] Cortex-M4 r0p1 processor detected
Info : [stm32f4x.cpu] target has 6 breakpoints, 4 watchpoints
Info : starting gdb server for stm32f4x.cpu on 3333
Info : Listening on port 3333 for gdb connections
    TargetName         Type       Endian TapName            State       
--  ------------------ ---------- ------ ------------------ ------------
 0* stm32f4x.cpu       hla_target little stm32f4x.cpu       running

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08006b80 msp: 0x20003400
Info : device id = 0x100f6413
Info : flash size = 1024 kbytes
auto erase enabled
wrote 131072 bytes from file /home/jigsaw/west-workspace/bms-firmware/app/build/zephyr/zephyr.hex in 4.429477s (28.897 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x08006b80 msp: 0x20003400
verified 103256 bytes in 0.972708s (103.665 KiB/s)

Info : Unable to match requested speed 2000 kHz, using 1800 kHz
Info : Unable to match requested speed 2000 kHz, using 1800 kHz
shutdown command invoked

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:
image
I also have PDF schematics for this board:

STM32 Dev Board Schematic.pdf

I hooked up wires like this:

USART3 TX TO PB10 Y9
USART3 RX TO PB11 Y10

STLINK SWCLK PA14 P4
STLINK SWDIO PA13 P5
STLINK NRST TO RST

(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:
bms_f405.zip

I really don't know what was gone wrong but my CPU is halting. Here is serial console output about BUS FAULT:

*** Booting Zephyr OS build zephyr-v2.5.0-22005-gca875f754e7d  ***
I: ThingSet Node ID (EUI-64): 38F46CE6AC0DAC1A
E: ***** BUS FAULT *****
E:   Instruction bus error
E: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x20003378
E: r3/a4:  0x00000008 r12/ip:  0xffffffff r14/lr:  0x0800434f
E:  xpsr:  0x21000000
E: Faulting instruction address (r15/pc): 0x24f7f4b4
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x20001180 (main)
E: Halting system

I have read many forums about this issue try to figure out whats going on. Someone suggested to add two lines

CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_COMPILER_OPT=""

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:

*** Booting Zephyr OS build zephyr-v2.5.0-22005-gca875f754e7d  ***
I: ThingSet Node ID (EUI-64): 38F46CE6AC0DAC1A
E: ***** MPU FAULT *****
E:   Instruction Access Violation
E: r0/a1:  0x00000000  r1/a2:  0x00000000  r2/a3:  0x200033f8
E: r3/a4:  0x00000008 r12/ip:  0xffffffff r14/lr:  0x080043b5
E:  xpsr:  0x21000000
E: Faulting instruction address (r15/pc): 0x43f7f2b4
E: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
E: Current thread: 0x20001180 (main)
E: Halting system

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

$ west build -t menuconfig

image

and change some values about MCU or something it saves .config file but when i command
$west build -b bms_f405 --pristine
it ignores my changed values. Is there a way to use menuconfig?Or menuconfig is wrong way to approach compiling firmware?

Many thanks.

@Retro-Fitt
Copy link
Author

It was an EEPROM issue. Since i didn't install an i2c EEPROM to my F405 board i believe it complained.
For those wondering you have to comment out CONFIG_EEPROM=y and compile again and volia.

image

image

BTW my PCB prototypes just came today here they are unassembled.

1699005715070
1699005715075

Next week i will assemble and test them.

@Retro-Fitt
Copy link
Author

Retro-Fitt commented Nov 7, 2023

@martinjaeger

I assembled my board and uploaded firmware for F072.

1699347895107
1699347895103

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 my first tests i used v23.0.2-gff09cfe branch. It unfortunately give me "Balloc succeeded" error:

image

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.

image

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:

image

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.

image

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?

@Retro-Fitt
Copy link
Author

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.)

image

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.
Also a side note: When i compile firmware without above parameters ram usage is like %91, with these parameters it is like %85 i am not sure whats going on because i compile same firmware without modifications. Anyway now it seems working as expected.

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:
image

And here is C5.1 and C5 are shorted together on PCB:

image

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":

image

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:
image
So first i checked if my current sense resistor value (I used 4mR instead of 1.5mR in original design.) on bms_15s80_sc.dts and it was shunt-res = <4000>; so it was ok. I measured sense resistor terminals without any load on BMS with my fluke but couldn't read any readings probably because of very small voltage. (0.37*0.004=0.00148Volts?) I checked SRP and SRN pins for short and continuity and measured REGOUT pin but no hardware issues. Then i checked bq76930 datasheet for SRP and SRN lines and noticed resistors are 100ohm instead of 1kohm so i desoldered 1kohm ones and soldered 100 ohm:

image

And it shows 0.04 Amps as expected:

image

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?
@martinjaeger Did i say something to offend you? If so i am sorry.

@martinjaeger
Copy link
Member

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.)

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.

2) Another issue was misreading voltage on Cell 6, Cell 7 and Cell 8.

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.

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

Great that you were able to fix this and thanks for posting the update.

@martinjaeger Did i say something to offend you? If so i am sorry.

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.

@thomasplaz
Copy link
Collaborator

Hi Retro Fitt,
Frank Richter and me used Martin Jäger's BMS to build a solar storage unit with a 9-cell battery and another solar storage unit with 15 cells. You can find the whole project (so far only in German at):
https://wiki.opensourceecology.de/Solarspeicher_(station%C3%A4r))

You can find the detailed instructions for building the BMS at
https://wiki.opensourceecology.de/24-48V_BMS

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.
https:/LibreSolar/bms-15s80-sc/tree/rev2

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:
https://gitlab.opensourceecology.de/soldorado-open-solar-system/solar-storage-controller-hardware
This is because we have had bad experiences in an operating state where, for example, the Mosfet discharge is closed, but the Mosfet Charge is still open.
The reverse current via the body diode and the resulting heat flow backwards through a closed Mosfet leads to the burning out of the Mosfets. Maximal currents in our arrangement go’s up to 35A.

In a second variant, the BMS board and the SNS board are combined on one board in Eagle. These files are linked at
https://wiki.opensourceecology.de/24-48V_BMS “Variant 2”.

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:
https://gitlab.opensourceecology.de/soldorado-open-solar-system/bms_software_prototyp3 and
https://gitlab.opensourceecology.de/soldorado-open-solar-system/bq769x0_mbed_lib

The new SOC calculation is not online yet, coming soon, if you need it immediately please let me know..
I hope I have given you an overview of what we have done and is maybe useful for you. If you have any questions please just ask.

@Retro-Fitt
Copy link
Author

@martinjaeger
@thomasplaz
Many thanks both of you for reply. Sorry to write late. I had some health issues, than life was busy...
Anyway i figured out that precharge mosfet source and drain pins are reversed in my schematic. I temporary soldered mosfet pins manually. Now precharge issue is fixed.

image

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.

I no longer have any hardware issues but i might have software issues which i will make new issue on firmware repo.

@martinjaeger
Copy link
Member

Ok, thanks for the heads up. Hope you are fine again.

Should we close this issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants