Communication issue between S32K144, MC33771C and the transceiver MC33664

[adrimen3668]

Hi, we are working with the MC33771C, s32k144 and the transceiver MC33664C and we have an issue.

We are using the example project "BCC_S32K144_Monitoring".

The problem occurs in the function "BCC_AssignCid".

When the instruction "status = BCC_Reg_Read(drvConfig, BCC_CID_UNASSIG, MC33771C_INIT_OFFSET, 1U, &readVal);" run, the status give us a "BCC_STATUS_COM_TIMEOUT" because the slave does not recieves response from the MC33771C. 

We capture the spi frame in the 'BCC_Reg_Read' in the "BCC_AssignCid" function and we notice that the master data output of the master does not end at '1'. We do not know if this matters..

The green signal is the master clock and the yellow is the master master data output. 

Here, the green signal is the master chip select and the yellow is the master master data output.

Here, the green signal is the serial data input of the slave and the yellow is de serial data output of the master.

The signal recieved in the slave was sent by the transceiver MC33664.

We test the tpl signals of the transceiver MC33664 and works well.

Clarifications:

1. The function BCC_SoftwareReset correctly send the spi frame.

The yellow is the master data output and the green is the slave data input.

2. We have correctly powered the board at 42.1 volts.

3.We are working on tpl mode.

Thanks in advance.

[leonggz]

hi, i'm encountering a similar issue on a customized board.. i wonder if your problem was solved?

[Q_man]

Yes, this thread was solved. There were multiple incorrect timings.

Please open a new thread an provide details what you do and what you observe.

W.

[Q_man]

Hi,

We capture the spi frame in the 'BCC_Reg_Read' in the "BCC_AssignCid" function and we notice that the master data output of the master does not end at '1'. We do not know if this matters..
=> No, this does NOT matter.

The BCC_Reg_Read() should trigger actually two SPI frames on the RX_SPI of the MC33664 as shown in the picture below.

The CMD would be the Read Request transmitted by the uC.
This CMD Echo is also received on the RX SPI, with a small delay.
Then the MC33771 should respond (RSP) to the Read Request, which should be visible on the RX SPI

Can you see a RSP on the RX SPI?

W.

[adrimen3668]

Hi,

No, we do not receive the RSP in the RX_SPI.

We only received the cmd_echo.

Any idea what kind of problem it could be?

Like I said earlier, the pcb is correctly powered at 42.1 volts.

Thanks in advance.

[Q_man]

Hi,

could you please check the following items:

1. prior to the read the following needs to happen:

1.1 the MC33664 needs to be enabled: the uC sets the EN signal and the MC33664 should indicate the INTB as result

1.2 the chain (MC33771) might need to be woken up:

the uC needs to send two short CSB low pulses with a fixed delay between them (note the timing in particular of the pause t2 must be between 500 and 700 us)

1.3 wake-up time of MC33771

after the wake-up pulse (1.2) has been issued a pause of e.g. 1ms should be considered before starting communication.

1.4. if a SW Reset messsage is used

after sending a SW Reset message a delay of >5ms is required before communicating

2. check uC TX SPI timing

For proper operation the uC TX SPI must follow some critical timings:

Please check f and g:

W.

[adrimen3668]

Hi, we check all the points and still not working.

1. prior to the read the following needs to happen:

1.1 the MC33664 needs to be enabled: the uC sets the EN signal and the MC33664 should indicate the INTB as result.

The yellow signal is the ENABLE and the green signal is the INTB.

1.2 the chain (MC33771) might need to be woken up:

the green signal is the chip select

1.3 wake-up time of MC33771

We put a delay of 1ms after the wake up

1.4. if a SW Reset messsage is used

Delay of 5 ms after the software reset.

2. check uC TX SPI timing.

In both photos the green signal is the CS_tx and the yellow signal is the CLK_TX.

Any other idea of what the problem could be?

Thanks in advance.

[Q_man]

Can you share information about the hardware setup you are using?

W.

[adrimen3668]

Hi, 

Our hardware setup is a replica of the evaluation board RD33771-48VEVM, with the diference that we use the MC33771C instead of the MC33771B.

Thanks in advance.

[Q_man]

Hi, its difficult to see, but it seems that the uC sends bit23 as high (Master / slave). This bit should be transmitted as low.
- low = uC Request

- high = MC33771 Read Response

The MC33771C will only react to a read request, if bit23 is low.

W.

[adrimen3668]

Hi,

We analyzed the frame again and this is what we got.

Data= 0000 0000 0000 0001    Master/slave= 0  Address=000 0001 Reserved = 00 CID=00 0000 MasterCounter: 0000 Reserved:00 Cmd=01 CRC: 1111 0100

In this picture we can see that the address bit is '0'.

We do not think that the frame is wrong because we are using the example project 'BCC_S32K144_Monitoring', and the bits match with what we have expected.

Do you have any other idea?

Thanks in advance.

[Q_man]

Can you capture the VCOM Pin of the MC33771C whilst performing the "Init"? Basically the VCOM should be either already on or turn on when the wake-up is transmitted on the TPL bus. Maybe you can capture the MC33664 Rx-CSB and the VCOM?

[adrimen3668]

Hi,

This can be the possible issue.

The VCOM port does not turn on when we send the wake-up.

We do not know the reason. What could be the reason?

The CS_RX works well.

Thanks in advance.

[Q_man]

Do you have a 2nd MC33771C hardware you can test with?

Can you completely power off the MC33771C hardware and retest (the VCOM) after a power on? VCOM should also be on for ~60s after initial power on.

[adrimen3668]

Hi,

I test and the VCOM was 'ON' during 60 seconds like you said.

I test the system again and now there is voltage in the VCOM after the AssignCid function, but still no answer from the bms.

There are two volts in the VCOM.

Any other ideas why it is not working?

Thanks in advance! 

[Q_man]

VCOM should be 5V!

Maybe you have to check your power supply: sufficient current capability and if it has a current limitation that it is set high enough.

[Q_man]

Hi, did you make any progress? Have you check you power supply configuration?

[adrimen3668]

Hi,

Now we have 5 volts in the VCOM for 60 seconds when we power on the pcb.

And 5 volts also when we send the function BCC_AssingCid().

The project that we are using is the BCC_S32K144_Monitoring.

But we still do not receive response from the mcc33771c.

Do you have any other idea?

Thanks in advance.

[Q_man]

Hi, do you see any response data on the MC33664 RX SPI? With a scope?

Can you share the schematics of you hardware? You can send it directly to my email: wolfgang.bihlmayr@nxp.com

Also note that the MC33771C will reset in case of no TPL bus activity (comm timeout ~1024ms).

[adrimen3668]

Hi, we only see the cmd echo in the rx_spi but no the response from the bms.

About the schematic, we are consulting with our hardware team.

Any other idea?

Thanks in advance!

[adrimen3668]

Hi,

We are checking all the parameters in the hardware.

When we reach the solution, we will let you know.

Thanks for the help!