RD33771-48VEVM Reference Design Data Type Problem

[m15871781742]

I am going to develop a BMS. I found the rd33771-48VEVM Reference Design on the NXP website.

When I study the SW driver package, I have some problems with the parameter definition.

The first problem is some parameter like 'u16VoltCell[15][24]' means the voltage of the cell in the package. The data type of this parameter is 'uint16_t'. I think the parameter associated with voltage, current, temperature should be 'float'.

The second problem is for the parameter 'u16VoltCell[15][24]', I think the '[15]' means it can have 15 mc33771 nodes for the BMS. as for the '[24]',[0] is stack voltage ,[1]...[14] means cell1..14, what are the rest of the bits for?

The third problem is the parameter 'u32ECCSignature[15]', I think the data type is 'uint32_t' according to the name, but the data type is 'uint16_t'. I don't know if there's an error here

RDTh33771-48VEVM Reference DesignRD

RD33771-48VEVM Reference Design

RD33771-48VEVM Reference Design

[TomasVaverka]

Hi Shao,

1. The MC33771 device datasheet tells you that all raw measurements are done in mVolts in the range [CTx_UV_TH .. CTx_OV_TH]. The MEAS_xxxx registers contain the measured values as a result of on-demand conversions.

Therefore the driver also stores the mVolt values to not waste time for conversion to float. It is up to the application to do float calculation based on those integer values.

2. Yes, the first index [15] means up to 15 MC33771 nodes, or clusters, where cluster ID = 0..14 is assigned to the device during initialization phase (enumeration).

The second index [24] means measurements obtained from the MC337771.

[0] = VStack

[1~14] = VCellx

[15~21] = Vtemperature

[22,23] = store Vadc-a, Vadc-b in debugging purpuse code, but no longer used in this code.

3. ECC signature is a 32-bit word, so you are right, is must be uint32_t. There is a copy/paste bug in the structure definition. Be cautious to change this in the *.h to uint32_t. Otherwise in case we have two or more clusters every next ECC value would overwrite the previous one because of this bug.

Best regards,

Tomas