Honda Insight Forum banner

Honda Fit LTO BMS Discussion....

16261 118
This thread is to discuss usage of the Honda Fit LTO Lithium block OEM BMS boards.

The LTO 12 cell blocks each have a 12 cells BMS with unique CAN ID.
Others have done some research on these and that info will shortly be added to this thread.

Using that info I have connected an LTO BMS to the BCM Replacer and am now able to read the cell voltages via the CAN bus. :)

We probably won't be able to enable the LTO balancing function, however this is a very useful addition to our armoury for people wanting to use the LTO packs.
It makes the purchase of an Orion2 less critical if you are prepared to do manual balancing when the cell voltage deviation indicates attention is reqd.
That may be a very infrequent occurrence as anecdotally the LTO blocks have been reported to stay well in balance.

As far as the BCM Replacer is concerned, you do not need a B board or tap modules if you don't want them.
The BCM Replacer will run with just an A board to communicate with the LTO stuff.
This halves the cost of the BCM Replacer system to around $400...


Note. One of the taps on the display is shown as 2.7v this is correct as the led in the BCM Fooler matrix causes this effect.
The other 11 taps are all around 8-900mv..
  • Like
Reactions: mmdepace
101 - 119 of 119 Posts

· Registered
Joined
·
30 Posts
No. Sorry. Without a working system we are stuffed.
Well, I finally gave in and bought a Renesas E8a debug probe, built a custom debug cable for the connectors I had added to the Fit LTO BMS, and installed the R8C development tools on an old Windows 7 laptop...

I almost couldn't believe it when I connected, opened a memory viewer, and was not met with a code protect ID check!
All of the ID bytes appear to have not been set (0xff == erased) and are in the middle of other "stuff".

I can read code/data in flash from both the CAN microcontroller and the microcontroller connected to the AFE/cell management IC! (I mucked up the code image for the CAN controller using soft breakpoints on flash but had already saved a full device memory dump first and think I can restore the area that got clobbered. ;-) I hope the resources used by the debug probe didn't wipe anything important out.

The documentation of R8c/36 (controllers) and E8a (probe) debug capabilities are thin but (Found "Users Manual: Hardware" ;-) there appears to be hardware single step and hardware address match breaks which should give me a lot of flexibility. If I can find the code that sends serial messages from the CAN controller to the Cell monitor controller I might find hints on how to initiate balancing. (Figuring out incoming CAN message decode would likely do the same.)

Scott.
 

· Registered
Joined
·
2,335 Posts
@Fishybob Suggest you start a new thread for this.

Do you have a legitimate copy of IDA Pro? If not, has someone added support for those Renesas MCUs as a plug-in for Ghidra or Radare?

Finally, you are going to want to check out ANGR which analyzes conditionals and branches.

ANGR won't work on your binaries because I think it uses the same plugins as Radare which, again, I don't think exist yet. You might want to pause and write that plug-in. It will probably save you a TON of work, since IIRC that plugin would enable use of both ANGR and Radare and/or Ghidra. There was some work on a cross-compiler for Linux a very long time ago, I think, that might inform this.

And finally finally, study the messages on the serial bus between the two microcontrollers. If you can spare an Arduino per BMS board, you can send the balancing commands yourself on that bus. Check out the AVR128DA28 which is easily breadboarded, has multiple serial ports, is 5V compatible, has healthy Arduino support via a project called DxCore, boots instantly because of a one wire debug that writes the code directly to flash and has no bootloader, and IIRC, in stock. Only one extra part is needed, a capacitor between power and ground. But it would be much better to understand the protocol that can activate balancing via the CAN bus.
 

· Registered
Joined
·
2,335 Posts
Perhaps it is time I started getting serious about my LTO conversion.

@Fishybob - I see that someone has created an RL78 plug-in for Ghidra in 2020... but there were a lot of parts in that family, so YMMV. But it might be good enough to bring Ghidra online for analysis of the binary.

I wonder how hard it is to create a symbol table for that manually? It may eliminate the need to manually annotate the assembly. I presume that you are using the disassembler that's part of the Renesas toolchain.

@anyone - What is the range of CAN bus IDs? Is it hex 201 though 20C (12 blocks, or six packs)? Did the Fit have three groups of these? (1.1 kWh * 18 = 19.8 kWh)?
 

· Registered
Joined
·
30 Posts
Perhaps it is time I started getting serious about my LTO conversion.

@Fishybob - I see that someone has created an RL78 plug-in for Ghidra in 2020... but there were a lot of parts in that family, so YMMV. But it might be good enough to bring Ghidra online for analysis of the binary.

I wonder how hard it is to create a symbol table for that manually? It may eliminate the need to manually annotate the assembly. I presume that you are using the disassembler that's part of the Renesas toolchain.

@anyone - What is the range of CAN bus IDs? Is it hex 201 though 20C (12 blocks, or six packs)? Did the Fit have three groups of these? (1.1 kWh * 18 = 19.8 kWh)?
1) Not familiar with the RL78 at all. (Just starting to get a familiar with R8c 36W/36Y. At least I believe I am looking at the correct docs now. ;-)
2) Investigating manual symbol table creation... (Yes, I am using disassembler in the Renesas HEW.)
3) Yes, I believe that (based on additional hardware) the Fit EV had 18 "packs" configured as 6S3P (6 series 60v pack = 360vc, ID 0x201..0x20c) x 3p.

The HEW debugger definitely clobbered some target flash (debug related exception vectors and debug code area.) I need to use FDT (Flash Development Tool) on a fresh target to grab unmodified flash images so I can restore original/functional BMS code image. (I already mangled the debug connector pads on one of my spare boards. I miss through hole robustness and visibility.)

Currently trying to understand CAN module clocking restrictions relating to emulation probe "stop mode" system clock changes. (I can get through about 6 seconds of boot before the instruction to take CAN0 controller out of sleep hangs the debugger.) Good news is that R8c/36 has 8 hardware breakpoints, two (imprecise) hardware data breakpoints, and a 4 branch/target or 8 data-access hardware trace.
 

· Registered
Joined
·
2,335 Posts
@Fishybob It looks like I was wrong about the processor family. You are correct that R8C is the family for the R5F21xxx... processors. The RL78 family parts seem to start with R5F1...

Still, the work done for the RL78 might be useful if it turns out to be needed.

I am curious as to how you are coming along. Also, you can purchase connectors for those debug pads. Here are part numbers I found that seem to work (Digikey):

SMT connector: 455-1570-1-ND (side entry type; apparently there is a top-entry type)
Cable connector: 455-1598-ND
Pins for cable connector: 455-1606-1-ND <=== out of stock, an alternative is suggested

The top-entry version might be better and would let you put glue gun glue or melty beads around the wires to keep them from breaking (very tiny) because you could put it on both sides of the cable connector, while with the side mount, one side of the cable connector is going to be against the PCB.
 

· Registered
Joined
·
30 Posts
The top entry socket reverses the cable pin order relative to the side entry for the single footprint on the board. I damaged a spare board trying to remove a top entry header I had just installed because I didn't want different debug cables based on connector style.

I was eventually able to grab clean flash images from the spare board I damaged. Using FDT I can capture/restore original flash contents to either controller.

I got the Renesas tools installed and working on my WIN10 desktop but the debugger (part of HEW) is still getting in the way of my finding "balance". If I don't make some progress on the CAN init issue soon I may switch back to the non-CAN controller for a while. The best clue I have so far was from inspecting registers after the first connection to a board which had been running. The board gets reset and some target resources get overwritten but many register retain their contents. Looking at the CAN registers I see the "CAN0 FIFO Received ID Compare Registers" are set to listen for ID 0x503. (This might be a broadcast ID the "CMU" is expecting from the "BMU".)

The E8a debug probe is in stock at Digikey and comes with an install CD for the tools... ;-)
Circuit component Bicycle handlebar Bicycle part Electrical wiring Line
 

· Administrator
Joined
·
14,251 Posts
Discussion Starter · #109 · (Edited)
Looking at the CAN registers I see the "CAN0 FIFO Received ID Compare Registers" are set to listen for ID 0x503. (This might be a broadcast ID the "CMU" is expecting from the "BMU".)
Nice progress. (y)

In the (40 LiPo cell) Lithium Honda CR-Z and CIVIC the 4 x 10 cell BMS boards listen for ID $501 from the BCM and get upset if they can't hear it on the BUS.
Some error bits change (get set) in the spare bytes at the end of the voltage data stream they are constantly outputting after a few seconds.
That sort of tallies with what you are seeing in the FIT and makes sense.

In the CR-Z the $501 packet is sent every 500ms, so pretty slow.

Attached is some activity $501 from the normal IMACAN bus on my CR-Z
You will note the 4 packet revolving cycle check byte on the end.

In the middle of this data capture is some other activity probably related to balancing..

The FIT has several groups of blocks with the same ID's so you might find it perhaps uses $501, $502, $503 etc etc to talk to specific groups?
If you have boards from other blocks see if that CAN0 FIFO register has the same listen value.

You could try throwing (sending) a four packet $503 repeating cycle at your board based on my data and see how it reacts.

1 22.4 1 Rx 501 8 06 DB B8 3E 8F FF 0B 2E
2 522.5 1 Rx 501 8 00 00 00 00 00 FF F0 7E
3 1022.4 1 Rx 501 8 06 DB B8 3E 8F FF 0B 00
4 1522.3 1 Rx 501 8 00 00 00 00 00 FF F0 50
 

Attachments

· Registered
Joined
·
30 Posts
If I don't make some progress on the CAN init issue soon I may switch back to the non-CAN controller for a while.
Taking a break from CAN controller/debugger frustration. Here is my take on the CAN controller init which gives a feel for code complexity based on resources initialized:
(Stuff after ";" are my comments.)

04000 EB40001C LDC #1C00H,ISP
04004 EB300000 LDC #0000H,FLG
04008 EB200000 LDC #0000H,INTBH
0400C EB10A0DE LDC #DEA0H,INTBL
04010 FC144000 JMP.A 04014H
04014 F52B16 JSR.W 05640H ; RAM test. (No SFR mods.)
04017 F56614 JSR.W 0547EH ; WDT ping CPU tests.
0401A F56927 JSR.W 06784H ; ? (No SFR mods)
0401D F51262 JSR.W 0A230H ; ? (No SFR mods)
04020 F5270B JSR.W 04B48H ; Config Port Direction.
04023 F5020C JSR.W 04C26H ; Config SSU. (timers and module standby)
04026 F56B0D JSR.W 04D92H ; AD init.
04029 F5400D JSR.W 04D6AH ; UART1/UART2 init.
0402C F5730D JSR.W 04DA0H ; CAN wake/init? (hangs debugger !SKIPPED!)
0402F F59A0B JSR.W 04BCAH ; DTC init.
04032 F51717 JSR.W 0574AH ; Timer init.
04035 F56415 JSR.W 0559AH ; AD input select and AD0 use?
04038 F5ED0B JSR.W 04C26H ; Timer RA0/RB/RE/RC/RD/RG use?
0403B F5560D JSR.W 04D92H ; AD input select.
0403E F52B08 JSR.W 0486AH ; ? (No SFR mods)
04041 F5FC2F JSR.W 0703EH ; ? (No SFR mods)
04044 F56908 JSR.W 048AEH ; ? (No SFR mods)
04047 F5441B JSR.W 05B8CH ; AD input select and AD0
0404A F5111B JSR.W 05B5CH ; ? (No SFR mods)
0404D F51C1B JSR.W 05B6AH ; CAN0 Mask/mailbox int enable.
04050 F50300 JSR.W 04054H ; Likely main() (timers/UART1/UART2/AD0 ints. DTC)
04053 F3 RTS ; Never gets here (expected.)
 

· Registered
Joined
·
30 Posts
... In the CR-Z the $501 packet is sent every 500ms, so pretty slow.
Thanks for the info/ideas (and the spare boards!) I will reread your CR-Z BMS comments for before I do any CAN spamming.
I think I should hook up the UART connections available on the debug connectors. (Gonna feel a bit silly if they are active and useful. ;-)

UPDATE:

Learning a lot about the R8c (and Renesas tool shortcomings for debug of existing binaries) but no further leads on "discharge"/"stop-discharge" CMU commands. Even the much less complex non-CAN controller is trashing my debug sessions with software reset in fairly early boot code. This code is small enough I may just print out a full disassembly and start in with the note taking...

I Have some high resolution scans of both sides of the BMS board and will try to determine if AN0-AN11 are for cell monitoring or discharge.

Really wish the tools were not causing such severe issues executing existing code... (Ah well. still feel VERY lucky the code was not protected.)

I inspected the serial traffic between the low voltage "CAN" side and the high voltage "cell" side and see slightly different traffic than I see in my notes from a few years ago...

CAN uC -> CELL uC (likely requesting cell voltages.)
00000000: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 08
0000000f: 81 00 00 00 00 00 00 00 00 00 00 00 00 00 07
0000001e: 82 00 00 00 00 00 00 00 00 00 00 00 00 00 06
0000002d: 83 00 00 00 00 00 00 00 00 00 00 00 00 00 05
0000003c: 80 00 00 00 00 00 00 00 00 00 00 00 00 00 08
0000004b: 81 00 00 00 00 00 00 00 00 00 00 00 00 00 07
0000005a: 82 00 00 00 00 00 00 00 00 00 00 00 00 00 06
00000069: 83 00 00 00 00 00 00 00 00 00 00 00 00 00 05


CELL uC -> CAN uC (likely reporting cell voltages but have not tried to decipher exact format other than this likely alignment and grouping.)
00000000: 80 7a 07 78 07 7a 07 7a 07 7b 07 7a 07 7a 07 7a 07 7a 07 7a 07 7b 07 7b 07 00 00
00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 05 7f 07 7f 07 7f 07 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 05 7f 07 7f 07 7f 07 00 00
61 62 36 49 68 34 60 00 29 0d
00000059: 81 7a 07 7b 07 7a 07 7a 07 7a 07 7a 07 7a 07 79 07 7a 07 7a 07 7b 07 7b 07 00 00
00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 05 7f 07 7f 07 7f 07 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 05 7f 07 7f 07 7f 07 00 00
61 62 36 48 68 34 60 00 29 0b
000000b2: 82 7b 07 7a 07 7a 07 7a 07 7b 07 7a 07 7a 07 79 07 7b 07 7b 07 7a 07 7b 07 00 00
00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 05 7f 07 7f 07 7f 07 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 05 7f 07 7f 07 7f 07 00 00
61 62 36 48 68 34 60 00 29 09
0000010b: 83 7a 07 7a 07 7a 07 7a 07 7a 07 7a 07 79 07 7a 07 7a 07 7b 07 7a 07 7b 07 00 00
00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0d 05 7f 07 7f 07 7f 07 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 06 05 7f 07 7f 07 7f 07 00 00
61 62 36 49 68 34 60 00 29 0a


Need to work on my gravel road, pick up a million Fir branches, and attend to other chores so it might be a while before I make progress.
(I did pick up the rest of Greentec Autos square packs on the assumption I will be able to understand the existing code or just write my own.)

Scott.
 

· Registered
Joined
·
30 Posts
Made some solid progress! (Snowed yesterday so I stayed inside with the wood stove and LTO CMU.)
  • Used board scans and very sharp probes to decipher "AFE" and how it is controlled for bleeding cells 1-11. (Cell 12 gets into a sea of discretes possibly to minimize leakage while CMU is not powered.)
  • Used debugger to manually trigger "discharge" of cells 1-11. AFE chip takes 11 I/O lines to switch 47 ohm "bleed" resistors across cells. Cell 12 is... "special"
  • Modified or bypassed target RAM tests/initi which were trashing debugger stack use. Have debug control over to running non-CAN controller.
  • I identified DMA destination buffer for UART2 messages from CAN controller.
  • Can see continuous "don't bleed" port writes sent to AFE via non-CAN Port 3&5 but I think it is from an ISR and there is big data breakpoint skid in ISRs.
Circuit component Passive circuit component Hardware programmer Electronic engineering Electronic component

;-)
 

· Registered
Joined
·
2,335 Posts
Fun stuff.

this sent repeatedly from the can MCU to the cell MCU might turn on the balancing resistors on cells 4, 6, 8 and 10 (or is it 3, 5, 7, 9; this is from memory, modifying your message above, ymmv)
80 00 00 00 22 00 22 00 22 00 22 00 00 00 08
81 00 00 00 22 00 22 00 22 00 22 00 00 00 07
82 00 00 00 22 00 22 00 22 00 22 00 00 00 06
83 00 00 00 22 00 22 00 22 00 22 00 00 00 05
 

· Registered
Joined
·
30 Posts
@Fishybob
...If not, has someone added support for those Renesas MCUs as a plug-in for Ghidra or Radare?
Found someone actively working on M16c support for Ghidra (silverchris/m16c) and have it decompiling difficult to understand assembly into much more condensed but still difficult to understand "C". Thanks again for mentioning Ghidra, I had never used it before.
 

· Registered
Joined
·
2,335 Posts
Wow, that's a pretty new repo.

I would jump in, but I have more pressing things at the moment, like making sure my car is fueling properly. My priority for balancing the LTO packs dropped some time back when I realized that I could have a quarter volt imbalance between the highest and lowest cell in a set of packs, and still have more usable capacity than a NiMH pack. And since some people were claiming that these packs were staying very well balanced in regular use. I figured I could move forward with my LTO build, and figure this out later. (you appear to be on track to beating me to it.)

If I recall, you are using these for your solar farm/powerwall, so losing capacity needlessly to imbalance is a bigger deal. I am guessing that you have some insights from a year+ of operating this that is motivating you to get this working now. Are you seeing a situation where a few cells are lower than the others, forcing all to be discharged except those? Have you found any cells in all those packs that exhibit higher internal resistance or high self-discharge, yet no sign of damage/having vented?
 

· Engine-Off-Coast
Joined
·
2,757 Posts
A little over a month ago I accidentally charged my LTO car to over 2.7 V/cell because I left my grid charger plugged in for over 36 hours. I can't believe a few things:

1 - Car didn't set on fire
2 - A month later the voltage delta still only 30mA
3 - Battery still performs really well, like no noticeable problems

We had a family tragedy and I wasn't (and am still not) doing well. That's how I ended up leaving it in for almost 2 days.

What I'm saying is the Toshiba LTO blocks are really hard to kill.
 

· Registered
Joined
·
30 Posts
I am back in the CAN controller code and have a debug connection to the CAN controller of a (sometimes) running system. If anyone wants to try spamming what looks like the broadcast ID 0x503 of a CMU (disconnected from cells) I believe the message data would need to start with one of the following byte sequences to do anything:
  • 0x50 0x02
  • 0x71 0x01 0xff 0x00
  • 0x71 0x01 0xff 0x01
  • 0x7f 0x31 0x72
  • 0x7f 0x36 0x72
  • 0x7f 0x10 0x78
That said, I would guess that the bleed-cell commands would likely be directed at specific board IDs so that is where I am looking next... (After I review Peters other CAN traffic notes.)

(EDIT)
After rereading this thread I am leaning toward thinking the balance smarts are in the CAN controller code. (The cell controller code that switches in the bleed resistors does so for a 16-bit bleed count. I could see that when these counts reached 0 the bleed resistors were switched off.) Glad I reviewed everyones efforts!
I will dig deeper into of the LTO CMU "0x503" packet decode...
 
101 - 119 of 119 Posts
Top