Hi there,

I have made some progress on analyzing the PCB on the BL4040 (Makita 40V battery). The main IC on the PCB are

- BMS (connected to the 10 cells and temperature sensor) : Lapis ML5236

- MCU : Renesas R5F100GFAFB

It seems the 2 IC are connected together through uart (BMS --> MCU). Maybe it rings a bell to some viewers here ? Maybe there is a tool to connect to the Renesas MCU.

Keeping you updated on the investigation.

Cheers.

Posted by: @zabieru

Can I use the EV2300 HDQ method to read TR data ?

You can try it. See my last posts from this topic: https://www.laptopu.ro/community/power-tools-battery-pinout/makita/paged/2/

@azzido thanks for your reply, some more investigations

- ML5236 (BMS) and R5F100GFAFB (MCU) are connected with SPI connexion (SDO, SDI, SCK) which makes sense for the BMS IC chip to send data (cells, temperature, states..) to the MCU for serial communication (TR pin) the external tool (charger, analysis tool, tool...)

- The MCU then seems to be connected for serial communication.

* pin 11 going to copper pads on the PCB (TOOLRxD, GND, VDD, RESET) to be used with a 1-wire tool [1] from Renesas for RL78 MCU family (not sure it is possible to read/analysis though). Then I don't know if EV2300 HDQ will work with this 1-wire pin ?

* pin 12 (TOOLTxD) connecting through a circuit to the TR pin on the battery (which is the data communication pin on the battery along with DS, CS, DT/WK).

- BL4040 external pin meanings ? CS=Chip-Select ? DS=Discharge ? DT/WK=WakeUp ? TR=TRansmission ?

Cheers

 [1] : https://www.renesas.com/jp/en/document/apn/rl78-microcontrollers-rl78-protocol-programmer-edition-application-note-rev100?language=en

Try looking up the appropriate patents.

@marmichalsku what particular patents should I search ? related to battery manufacturer or to the chips ?

I have found the patent regarding battery communication. The protocol is Half Duplex UART over TR pin

https://patentimages.storage.googleapis.com/cd/88/2e/6196a4d6c2aa34/US20210075243A1.pdf

Sorry for reviving an old thread, but I just wanted to say I have spent some time reverse engineering this protocol and I have made some progress.

I am able to monitor messages sent between the batteries and a charger, and see things like the model numbers being sent back and forth.

I have documented my findings on GitHub: https://github.com/Malvineous/makita-xgt-serial

If anyone makes any progress on figuring out the structure of the messages please let me know (ideally submit a PR with your corrections/additions, or open an issue there and tell me what you've discovered.)

I am waiting on parts so I can properly interface a Raspberry Pico with the TR line, as I can only receive data at the moment and not send it.  Once I receive parts I will see if I can start sending messages to a battery to see if that sheds any light on how the protocol works, as I can't really see any patterns at the moment in the command numbers.

@malvineous 

Very good documentation.

My question is: Does Makita allow clearing the errors through the protocol ?

Thanks!  We don't yet know enough yet to figure out whether you can reset errors or not.  I suspect there probably is for simple errors.

According to the patent there is a fuse in the battery that can be blown by a software command in case of catastrophic error, so if that fuse has blown there would not be a way to reset it unless you soldered in a replacement component for whichever one has the fuse in it.

I am hoping to get enough code working to simulate a battery, as I can then connect my simulated battery to a real charger and pretend there is a fault, to catch any commands the charger sends that might kill the battery.  Once we know what those are we can do some experimenting to see whether they can be reversed to undo the effects and get a battery working again.

@malvineous 

Please contact me on Whatsapp to work together (contact page).