[retepsnikrep]

If you look at my captured 501 data you can see the CR-Z checksum for various packet samples.
The LTO is probably very similar.

If you put my live data through your checksum code do you get the same answer?

 

[Fishybob]

If you look at my captured 501 data you can see the CR-Z checksum for various packet samples.
The LTO is probably very similar.

If you put my live data through your checksum code do you get the same answer?

The check on an LTO 0x503 message is that LSnib(SUMnib(data)) must be 0.
The check on a CR-Z 0x501 message could be that LSnib(SUMnib(data)) must be 2:

522 sum-nibs(00 00 00 00 00 FF F0 7E) = 0x42, LS-nib(0x42) = 2
523 sum-nibs(06 DB B8 3E 8F FF 0B 00) = 0x82, LS-nib(0x82) = 2
524 sum-nibs(00 00 00 00 00 FF F0 50) = 0x32, LS-nib(0x32) = 2
525 sum-nibs(06 DB B8 3E 8F FF 0B 2E) = 0x92, LS-nib(0x92) = 2
526 sum-nibs(00 20 00 00 00 FF F0 7C) = 0x42, LS-nib(0x42) = 2
527 sum-nibs(06 DB B8 3E 8F FF 0B 00) = 0x82, LS-nib(0x82) = 2
528 sum-nibs(00 20 00 00 00 FF F0 5E) = 0x42, LS-nib(0x42) = 2
529 sum-nibs(06 DB B8 3E 8F FF 0B 2E) = 0x92, LS-nib(0x92) = 2

None of the CR-Z 0x501 data start with bytes that are of interest to the LTO CAN 0x503 message decoder (as best I can tell.)

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

This LTO serial traffic to the cell controller suggested by Sean appears to share the same data check as the 0x503 CAN data... ;-)

 

[*sean*]

Nice job with the checksum puzzle. It is indeed a four-bit twos-complement checksum. To generate the checksum, add all the nibbles of the data, xor with 0x0f (that is, flip all the bits), add 1, and the least four bits of the result is the checksum. The trick is knowing what to include in the count! To see if data with the checksum is good, the sum of all nibbles including the checksum nibble should be zero, as you know.

 

[Fishybob]

Nice job with the checksum puzzle...

Ghidra (w/ M16c plugin) is definitely a big help. Thanks again for mentioning it.

Found the CAN id offset from 0x201 (0x0..0x0b) in data FLASH. Need to modify a byte in 2 places and modify the subsequent bytes used as checks but looks like it could be a clean modification. "Just" need to solder on a debug connector and carefully use the probe with FDT so you don't trash target flash.

 

[*sean*]

Found the CAN id offset from 0x201 (0x0..0x0b) in data FLASH. Need to modify a byte in 2 places and modify the subsequent bytes used as checks but looks like it could be a clean modification. "Just" need to solder on a debug connector and carefully use the probe with FDT so you don't trash target flash.

You don't really need an R8C to read and write memory; you can do it with an Arduino if you implement the protocol: https://www.renesas.com/us/en/docum...tandard-serial-io-mode-protocol-specification

 

[Fishybob]

You don't really need an R8C to read and write memory; you can do it with an Arduino if you implement the protocol: https://www.renesas.com/us/en/docum...tandard-serial-io-mode-protocol-specification

The devices are both R8c/3x and use a funky "single" wire debug connection via MODE pin (and RESET) in place of UART plus monitor. I only bought the E8a probe after giving up on finding something I would have full control over.

 

[Fishybob]

...Message data that starts with "0x71 0x01 0xff 0x00" and "0x7f 0x10 0x78" and meets checksum condition should be inspected. Other starting data has external gating conditions beyond correct checksum.

Painfully slow progress... The "external gating conditions" appears to be that the module ID is 0x201.

All modules IDs (0x201 - 0x20c) accept 0x503 (broadcast?) messages that have correct checksum and have data starting with one of the following sequences:

• 0x71 0x01 0xff 0x00
• 0x7f 0x10 0x78

Modules with ID == 0x201 also accept
0x503 broadcast messages that have correct checksum and have data starting with one of the following sequences:

• 0x50 0x02
• 0x71 0x01 0xff 0x01
• 0x7f 0x31 0x72
• 0x7f 0x36 0x72

 

[Fishybob]

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

Yep, byte bleed counts for each cell are sent in 12 consecutive bytes after the 0x8# header.
I found the array of bleed words and can use the debugger to force valid messages with non-zero bleed counts.
I can see where non-zero bleed counts could originate in the code but am having trouble tying it to any CAN message.
(There are at least 10 gating flags any one of which can force zeroing of bleed counts.)
...slowly...

 

[Fishybob]

So slow... Turns out there are two similar but independent code bases present in the CAN micro. I started in one, transitioned to the other and now see a data flash check that triggers a jump back to the first. Both codebase flows are controlled by a pile of global variables/flags which are proving fairly difficult to crack. Still trying to connect UART message with non-zero bleed back to flags set based on CAN message. Probably need to step back and let my brain clear... ;-)

 

[Mario]

Bootloader vs application, maybe?

 

[*sean*]

I believe that the second code base is smaller and executes if a fault is found, just like the ECM has such a mode to run the fuel injectors in case of a fault as was mentioned in SB 03-012 (can't remember the number, the one with all the details about the codes that the service manual doesn't get into.) Chances are that only the main code base does balancing.

controlled by a pile of global variables/flags

Thus the recommendation to consider reconstructing a symbol table to label these (somehow, not sure if that would work in the Renesas assembler and not sure if this makes sense in Ghidra). Ugh

For the small number of blocks which go into an LTO build I am tempted to disconnect the CAN MCU from the battery MCU and connect a TTL to RS-485 adapter to the serial isolator and run every one to another RS-485 module attached to a Teensy 4.1. The Teensy 4.1 has eight serial ports so it could talk to four packs. The Teensy has a USB interface that runs USB native high speed and with a 600 MHz processor it does not require playing games to log without blocking which must be done for an Uno or Mega. I have played with a Teensy in this way recently and it was glorious!!!! to be able to log verbosely and see no impact to serial timing!!! This actually may be a simpler approach than futzing with CAN.