Need guidance working on MC33664 / MC33772B TPL communication

SONAL · ‎11-18-2021

Hello,
I am working on MC33664 / MC33772B TPL communication. I am using 3th party MCU to communicate with MC33664. I follow up the documentation and I already have a response from the SPI2 side of MC33664.

I have a problem on the understanding the response part. (I have some doubts on what I am sending as well but at least I am getting a response)

Let me explain:
spiClk = 2000000;                            /My SPI Clock speed for the master
pinRole_Init(NXP_EN, OUTPUT);   /Enable of MC33664
pinRole_Init(NXP_INT, INPUT);    /INT pin of MC33664

//Data to send

uint8_t data[64];

data[0] = {00}; //This is my initialisation data that says one Cluster only
data[1] = {01};
data[2] = {00};
data[3] = {01};
data[4] = {00};
data[6] = {01};
data[7] = {75};
data[8] = {03};
data[9] = {00};
data[10] = {03};
data[11] = {10};
data[12] = {00};
for (int i=13; i < sizeof(data); i++){ Rest of the data is 0x00
data[i] = {00};
}

//Enable the NXP
WriteOutput(NXP_EN, HIGH);
SPISettings(spiClk, MSBFIRST, SPI_MODE1); //set the SPI channel MSB fırst and Mode1
StartSpi->beginTransaction();
WriteOutput(VSPI_SS, LOW); //pull SS slow to prep other end for transfer

//Log the data which is sent to the MC33664
print("SentData; ");
for (int i=0; i < sizeof(data); i++){
print(data[i]);
}

//Check if INIT is active
if ( ReadInput(NXP_INT) ){
spi_SendData->transfer(data, sizeof(data)); // When the data is sent, receiving data is replacing the data[] variable.
println("DataSent!!!");
Serial.print("\n");
}

WriteOutput(VSPI_SS, HIGH); //pull ss high to signify end of data transfer
StopSpi->endSPITransaction();
WriteOutput(NXP_EN, HIGH); //this should be low but it is not working if it is low

//incoming data
print("IncoData; ");
for (int i=0; i < sizeof(data); i++){
Serial.print(data[i]);
}

********************************************************************
The output of the debug code is:
SentData; 010100175303100000000000000000000000000000000000000000000000000000 DataSent!!!
17:15:48.211 -> IncoData; 0012801280016512912811330000000000000000000000000000000000000000000000000000
17:15:49.603 -> SentData; 010100175303100000000000000000000000000000000000000000000000000000 DataSent!!!
17:15:49.603 -> IncoData; 0012801280016512912811330000000000000000000000000000000000000000000000000000
17:15:50.995 -> SentData; 010100175303100000000000000000000000000000000000000000000000000000 DataSent!!!
17:15:50.995 -> IncoData; 0012801280016512912811330000000000000000000000000000000000000000000000000000
17:15:52.419 -> SentData; 010100175303100000000000000000000000000000000000000000000000000000 DataSent!!!

Now I need to interpret the incoming data. And the problem starts here. Could anyone can help me to interpret the incoming data once and then I can continue coding for the rest of the communication.

Best Regards.

SNL · ‎12-06-2021

Hello again, We still didn't get any solution on our communication problem. Please check the following attachments.

I'm wondering if you can suggest anything to help with this following scenario...

I have a 33771BTPLEVB connected to a 33664EVB and I'm using an 3th party MCU frontend.

The TX_SPI and RX_SPI both use "mode_3" and a clock of 2MHz

The following NOP() commands are sent to the 33771BTPLEVB ....

BCC_PackFrame(0xAA55U, 0x00U, 0U, BCC_CMD_NOOP, txBuf);
status = BCC_MCU_TransferTpl(drvConfig->drvInstance, txBuf, drvConfig->drvData.rxBuf, 1);

I (560) Master Tx: aa 55 00 00 00 e7 00 00
L: 368 Results RxLen 48
I (560) Slave Rx: 2a 55 00 00 00 e7 00 00 00 00 00 00 00 00 00 00

BCC_PackFrame(0xA5A5U, 0x00U, 0U, BCC_CMD_NOOP, txBuf);
status = BCC_MCU_TransferTpl(drvConfig->drvInstance, txBuf, drvConfig->drvData.rxBuf, 1);

I (800) Master Tx: a5 a5 00 00 00 82 00 00
L: 368 Results RxLen 48
I (800) Slave Rx: 25 a5 00 00 00 82 00 00 00 00 00 00 00 00 00 00

BCC_PackFrame(0xFFFFU, 0x00U, 0U, BCC_CMD_NOOP, txBuf);
status = BCC_MCU_TransferTpl(drvConfig->drvInstance, txBuf, drvConfig->drvData.rxBuf, 1);

I (1040) Master Tx: ff ff 00 00 00 3f 00 00
L: 368 Results RxLen 48
I (1040) Slave Rx: 7f ff 00 00 00 3f 00 00 00 00 00 00 00 00 00 00

BCC_PackFrame(0xBC3CU, 0x00U, 0U, BCC_CMD_NOOP, txBuf);
status = BCC_MCU_TransferTpl(drvConfig->drvInstance, txBuf, drvConfig->drvData.rxBuf, 1);

I (1280) Master Tx: bc 3c 00 00 00 34 00 00
L: 368 Results RxLen 48
I (1280) Slave Rx: 3c 3c 00 00 00 34 00 00 00 00 00 00 00 00 00 00

with the following results:

1.I consistently lose the first bit in the reply.

2.I believe bit 23 should also be set as in the MC33771 datasheet.

3.During the software setup stage

Writing a HEX value of 0x41 to register 0x1 doesn't make sense as bit 6 is always "0" ??

E (2810) bcc: BCC_Reg_Write
E (2810) bcc_communication: BCC_Reg_WriteTpl cid 0x0 regAddr 0x1 regVal 0x41
E (2820) bcc_communication: BCC_PackFrame data: 0x41 addr: 0x1 cid: 0x0 cmdCnt: 0x2

E (2830) bcc_communication: BCC_CalcCRC
BCC_PackFrame frame [00] [41] [01] [00] [02] [72]

E (2840) bcc_peripheries: BCC_MCU_TransferTpl drvInstance: 0 rxTrCnt 1
I (2840) BCC_MCU_TransferTpl RXBUF: : 00 01 01 01 01 1d 00 00 00 00 00 00 00 00 00 00
I (2850) BCC_MCU_TransferTpl RXBUF: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I (2860) BCC_MCU_TransferTpl RXBUF: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I (2870) BCC_MCU_TransferTpl RXBUF: : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
I (2880) BCC_MCU_TransferTpl TXBUF: : 00 41 01 00 02 72 00 00
txBuf[BCC_MSG_IDX_CNT_CMD] 2
L: 327
L: 351 millis: (10) 12
L: 358
L: 365
I (3010) Master Tx: 00 41 01 00 02 72 00 00
L: 368 Results RxLen 48
I (3010) Slave Rx: 00 41 01 00 02 72 00 00 00 00 00 00 00 00 00 00

Any suggestion would be welcome at this stage

Regards

SNL · ‎11-30-2021

Dear Jozef
Right now we have FRDM33771BTPLEVB evaluation board and there the termination for SPI_COM_EN is via 10K resistor by default on the board.

We have a solid led light on the Vcom led after sending wake up pattern on the chip select pin on the TX side of the MC33664.

We are looking for the next step. How do we send the INIT[CID]. Is this data correct to send over SPI to MC33664 for init ing the CID over TPL ?

//Data to send
data_[0] = {0x00};
data_[1] = {0x01};
data_[2] = {0x03}; //Data1
data_[3] = {0x00};
data_[4] = {0x03};
data_[5] = {0x75};

data_[6] = {0x00};
data_[7] = {0x01};
data_[8] = {0x01};
data_[9] = {0x00}; //Data2
data_[10] = {0x01};
data_[11] = {0xf4};

data_[12] = {0x01};
data_[13] = {0x01};
data_[14] = {0x01}; //Data3
data_[15] = {0x00};
data_[16] = {0x02};
data_[17] = {0x28};

data_[18] = {0x00};
data_[19] = {0x01};
data_[20] = {0x01}; //Data4
data_[21] = {0x01};
data_[22] = {0x01};
data_[23] = {0x1d};

SONAL · ‎11-22-2021

Hello Jozef

We didnt want to share private information public. But anyway I am not able to send you a private message for some reason(limitet on my end by NXP)

Our Annual sales planned 5K after your chip crises ends.

This is our NDA case.
https://support.nxp.com/s/case/5002p00002by9yNAAQ
Eva from NXP NDA team working on it (I dont know why you dont see it on your systems but we already filled the questionnaire with Eva and sent it to NXP tech support)
I can share with you via e mail again but I dont know your mail.

Eva
Technical Support - NXP Semiconductor

SNL · ‎11-22-2021

Hello Jozef

Annual volume planned 5K after your chip crises ends but for the rest of the information
Please kindly send me an e mail for the information(which I already declared them through your NDA process, but anyway I can tell again via e mail)

Best Regards.

SONAL · ‎11-21-2021

Hello,
I am still working on the problem, nothing gives me a clue why I am getting this shifted RX response. I would like to share some Oscilloscope outputs related with the Data_Tx, Data_Rx signals as well as the TPL_N and TPL_P signals. Maybe it helps someone to figure out what I am doing wrong. The response signal (RX) is same even If the TPL signal line is attached to MC33772 or not.
It seems like a one bit shifted response.

Data_Rx and TX signalsTLP lines are not attachedTPL signalTPL signals from N and P lines

JozefKozon · ‎11-22-2021

Hello Sarper,

thank you for the additional information. I have contacted an application team for an advise to the issue. Could you please provide the following information? Especially the Annual Volume.

Customer: SONAL RENEWABLE ENERGY

End Customer: ?

End Application: ?

Country: Netherlands

Annual Volume: ?

With Best Regards,

Jozef

SONAL · ‎11-22-2021

You can sort out the administration problems with SNL (Same domain I am working on Admin team)
This message for the App team:
I am still working on the solution. As you can see form the oscilloscope screen the data I am receiving is the shifted representative of the sent data for some reason. And to see the corect data I played with the SPI settings little bit. When I have changed the SPI settings to ( LSBFIRST, SPI_MODE0) I saw that I am receiving the exactly same data.

I am getting the interrupt from MC33664 INT pin (falling edge) every time when I use SPI_SS pin.

Let me know if you want me to try anything else to identify the problem. Maybe a bit-stream to get CHIP ID or something like this would be beneficial.
Best Regards

JozefKozon · ‎11-22-2021

Hello Sarper,

please see below an answer from the application engineer. Have you used one of the recommended transformers? Recommended transformers are SUMIDA ESMIT-4180/C, PULSE HM2102NL, PULSE HM2103NL.

Regarding the NDA email. Could you please resend the required information here? I don't know in which case you have asked for them. However some of the information cannot be shared publicly and you would need to create a case, so I can share them. Do you have the MC33664 and MC33772 datasheets?

DESCRIPTION

The shifted RX message is the message confirmation of the transmitted message on TX pins. This is a normal feature of the MC33664 to check SPI connections between MCU and MC33664.

All terminations between the MC33664 physical layer and the MCU can be confirmed.
SPI transmit and receive messages are confirmed by performing a message transmit.
The transmit message is received bit for bit with an additional phase delay. Performing
this operation confirms the CSB_TX, SCLK_TX, DATA_TX, and CSB_RX, SCLK_RX,
DATA_RX are terminated between the MCU and the MC33664.

With Best Regards,

Jozef

SONAL · ‎11-26-2021

Dear Jozef

We have signed the NDA days ago and we cant still access the required resources. I am losing a trust on this issue. Is there any action that we can take on our side. Or the process itself is painfully slow on your side.

SONAL · ‎11-22-2021

What I understand form the Application Layers response is:
I am done with the MC33664 part but I need to send the correct data to receive an answer from MC33772 side.
Is that understanding correct?
If it is correct, is there a reference message (Decimal please) that I can send for testing if the MC33772 side is responding nicely. After knowing this I can go further and deeper on coding the required library.

Why they asked if I used the reference pulse transformer? Did they see any problem on the pulse transformer oscilloscope outputs?

Best Regards.

SONAL · ‎11-22-2021

Hello Thank you for the replay

Yes we use the recommended transformer. We are using PULSE HM2102NL it is a single channel TPL transformer one of your preferred transformer.

Related with NDA: With all my respect I am sorry but I cant share the NDA related documents here since it is a requirement from NXP that I am not sharing this information public. Please send us an e mail privately to info@sarperonal.com then we can send you all the requested information.

Best.

JozefKozon · ‎11-30-2021

Hello Sonal,

please check the MC33772B datasheet rev. 6 section 10.2 for the TPL communication. Its very good described there. The SPI_COM_EN must be connected to GND for the TPL communication.

For transformer communication, it is recommended the device be terminated as shown below.

To verify the communication you can send from the MCU to MC33772B a No operation command. Please refer to section 10.4.4 in the MC33772B datasheet.

With Best Regards,

Jozef