kiev
Posts: 1421
Joined: Sun May 03, 2015 7:15 am
Location: The Heart o' Dixie
Contact: Website

Re: CMU board notes, eprom, cell numbering

Sun Dec 20, 2020 6:20 pm

i don't remember why, but the Seiko data sheet for the S93C76A seemed to be a good match, http://www.farnell.com/datasheets/46815.pdf
and there seems to be an ABLIC version that is about the same also.

i had plenty of false readings using the Github arduino code which may have been related to the use of the ORG pin on some of the other versions such as the 93C76C, but i don't recall that either.
kiev = kenny's innovative electric vehicle

coulomb
Posts: 265
Joined: Sun Jun 10, 2018 8:32 pm
Location: Brisbane, Australia

Re: CMU board notes, eprom, cell numbering

Wed Dec 23, 2020 6:15 pm

DBMandrake wrote: Finding the secret sauce to easily renumber CMU's using a readily available third party diagnostic tool such as Hobdrive / icarsoft etc (no soldering/eeprom swapping) would be a breakthrough for the DIY and aftermarket repair and servicing of these battery packs.

I'm making slow progress on reading CMU firmware, and I think I've got to the stage where I can speculate how this happens.

1) It may be necessary to start with a CAn bus message (on the bus that CMUs are on, I don't know if messages from the main CAN bus pass through the BMU to the CMU) with message ID 0x3C3 (the same one that does bypassing), with D4 set to 4 (or at least, has D4[2] set). You can't say "leave the bypass bits alone", so you have to choose what you want with the bypass bits if you want to send a 3C3 message. All zeroes for the rest of the packet should force no bypassing.

2) The BMU sends the following 5-byte packet over the daisy chain, which connects to UARTD1 on the CMU processors:
00 FF 0F 00 0E
The first byte (D1) appears to be unused, and it initialised to 0. But the BMU may send different contents.
The next 3 bytes are what sets the CMU ID. We want CMU ID 1 at the start of the chain, and strangely this is in about the middle of a table. So we need 6 non-zero pairs of bits, starting with the LSBs of D2, indicating that we don't want IDs 7, 8, ... 12. With bits 4 and 5 set to zero, the first BMU sets its ID to 1, and the rest of the bits of D2 and D3 have to be zero, or it will get cancelled. I have set both bits in the pair in my example; sometimes the CMUs send only odd bits (so e.g. D2 would be 0x55), or even bits (0xAA), or both bits (0xFF, as I have here).
The last byte (D5) is the sum of bytes D2-D4.
[ Edit: these packets are probably sent at 300bps; see next post. ]

I believe that a task function is awoken that will save the new ID into EEPROM (the first word, it seems to me, though it's possible that it moves around).

So: not terribly convenient perhaps, but it should be possible to make up a gizmo that plugs into the appropriate connector and sends the bytes.

[ Edit: "first byte" -> "first word" ]
Last edited by coulomb on Thu Dec 24, 2020 6:21 am, edited 1 time in total.

coulomb
Posts: 265
Joined: Sun Jun 10, 2018 8:32 pm
Location: Brisbane, Australia

Re: CMU board notes, eprom, cell numbering

Wed Dec 23, 2020 9:38 pm

Anyone know what the crystal frequency is? The processor manual (if I have the right one) says it will work with 4.0 - 20.0 MHz crystals.

I don't know how to look this one up:

Image

It's almost like y.0X, with the leading "y" in a cursive font. [ Edit: either dot zero X or dot oh X. ] Maybe the cursive "y" is a manufacturer's logo. I did a quick search, but I don't know how to find those either.

It looks like the bit rate of uart1, which does the auto renumbering, is the clock frequency divided by 130*8 = 1040, so it might be 9.98 Mhz for 9600 bps. I'd say 10.000 MHz (9615 bps, 0.1% fast) would be close enough. Perhaps the "X" represents the roman numeral 10.

[ Edit: Oops, that's Uart 0, which seems to be for testing only (the TXD0 and RXD0 pins seem to come out only to testing pads). Uart1 seems to have /256 and /130, for 1·10⁶ / 256 / 130 = 300.48 bps. ]

Or it could be 20.000 MHz and 19 200 bps. [ Edit: 20 MHz and 600 Hz. ] But I would think that they'd want to stay away from the absolute upper frequency limit of operation. Especially on a CMU, where power consumption is paramount. [ Edit: also, 9600 and 300 bps seem "more standard" to me than 19 200 and 600 bps. ]

kiev
Posts: 1421
Joined: Sun May 03, 2015 7:15 am
Location: The Heart o' Dixie
Contact: Website

Crystal Marking

Thu Dec 24, 2020 8:05 am

On my board the crystal is marked "X0 . n" . It appears to be a murata part, 10Mhz, based upon the marking code,

https://www.murata.com/products/product ... 9743212000
kiev = kenny's innovative electric vehicle

coulomb
Posts: 265
Joined: Sun Jun 10, 2018 8:32 pm
Location: Brisbane, Australia

Re: Crystal Marking

Thu Dec 24, 2020 5:59 pm

kiev wrote:It appears to be a murata part, 10Mhz, based upon the marking code

Brilliant, thanks! [ Edit: I wasn't expecting a "resonator"; I don't really know the difference. I remember Murata made 455 kHz ceramic resonators (for radio IF filters) in the 1970s. ]

So that's confirmed then: the auto-renumber data is at 300 bps, and the test/debug data is at 9600 bps.

Return to “Batteries and Battery Management”