topic Re: MC33664 and MC33772B Communication Issues in Power Management

MC33664 and MC33772B Communication Issues

andrchen — Tue, 04 Mar 2025 21:16:49 GMT

Hello,

I am currently dealing with communication issues between my MCU(STM32F4)/MC33664 and an off-the-shelf system that contains a MC33772B. I cannot access the MC33772B at all, other than the TPL pins, it is internally powered by the system that it is monitoring.

My MCU is connected to my MC33664 over 2 SPI lines, and I have verified transmission from the SPI lines to the RDTX+/- pins. Effectively, the hardware that I have is "working". However, despite the messages that I'm sending, I'm not receiving any response from the off-the-shelf MC33772B.

Here is my current process:
1. Initialize the MC33664 device by triggering the EN pin and monitoring the INTB pin. (This step was pulled from SDK online and timing was verified with oscilloscope)

2. Wake up TPL by flipping CSB pin on MC33664 (as below) (also timing verified).

static inline void MC33664_WakeUpTpl(void)

{

MC33664_WriteTXCSBpin(0);

delay_us(21U);

MC33664_WriteTXCSBpin(1);

delay_us(600U);

MC33664_WriteTXCSBpin(0);

delay_us(21U);

MC33664_WriteTXCSBpin(1);

delay_us(1000U);

}

3. Send Software Reset Signal
data = 0x0010 (write to software reset bit)

addr = 0x03 (write to SYS_CFG1 register)

cid = 0

cmd = 0x03 (global write)

4. Send CID write signal
data = 0x0001 (write to CID)

addr = 0x01 (in INIT register)
cid = 0
cmd = 0x02 (write cmd)

5. Send CID read signal
data = 0x0001 (read one register)
addr = 0x01 (INIT register)
cid = 1 (check if it is written)

cmd = 0x01 (read cmd)

For this sequence, the only messages that I read on the RDTX+/- lines are the messages that I am sending. Is there a problem with this sequence? Is there another sequence I should try?

As well, I'm wondering what the timing requirements are for the TPL communication. I presently have a 16us delay between my SOM signal and the first logic bit of my message, and have a 26us delay between my last logic bit and my EOM signal. I believe this has something to do with the STM32 HAL SPI library, but I'm wondering if this is even a problem in the first place. If I use the HAL blocking SPI_Transmit functions, there is also a delay between the 4th and 5th bytes sent (I'm guessing due to the buffer size of the SPI transmit), I'm wondering if this is a problem as well. (I believed that it would be and resorted to using the HAL_DMA version of SPI_Transmit)

Thanks!

Re: MC33664 and MC33772B Communication Issues

guoweisun — Fri, 07 Mar 2025 00:57:10 GMT

For the hardware,please show us your connection circuit for your test platform.

For the TPL communication could you please catch some waveforms for better reveal your issue.

Re: MC33664 and MC33772B Communication Issues

andrchen — Fri, 07 Mar 2025 05:17:42 GMT

I've attached images of our schematics, the physical connections are on a PCBA.

I've also attached screenshots of our TPL communication.

Re: MC33664 and MC33772B Communication Issues

andrchen — Mon, 10 Mar 2025 22:56:31 GMT

I'm wondering if the issue may be CRC related? I am using the CRC calculator from the SDK, can you confirm what they intended CRCs are for the messages that I've outlined above?

Re: MC33664 and MC33772B Communication Issues

guoweisun — Mon, 17 Mar 2025 03:20:31 GMT

the CRC is used to ensure consistency (during transmission) of each individual 40 bit message on the bus and is calculated for the for the bits[39..8].

If you transmit a message you have to calculate the CRC based on the data you sent and add that CRC to the message.
If you receive a message you have to calculate the CRC_calc of the received message bits[39..8] and compare it with the received CRC_rx bits[7..0]. The data is consistent if CRC_calc == CRC_rx. If not consistent the data has to be ignored!

To ensure READ or WRITE commands you have to check the data inside the frame.

Re: MC33664 and MC33772B Communication Issues

andrchen — Tue, 18 Mar 2025 04:12:53 GMT

Thanks for the explanation!

I understand that the importance of the CRC, I understand that without the CRC the MC33772b won't respond. I do wonder if the CRCs that I'm calculating are correct. While I am using the provided calculator function in the SDK, I want the following CRC calculations to be verified, as well as the entire message process and message contents.

1. Send Software Reset Signal
data = 0x0010 (write to software reset bit)

addr = 0x03 (write to SYS_CFG1 register)

cid = 0

cmd = 0x03 (global write)

CRC = 0x37

2. Send CID write signal
data = 0x0001 (write to CID)

addr = 0x01 (in INIT register)
cid = 0
cmd = 0x02 (write cmd)

CRC = 0x0B

3. Send CID read signal
data = 0x0001 (read one register)
addr = 0x01 (INIT register)
cid = 1 (check if it is written)

cmd = 0x01 (read cmd)

CRC = 0xD4

I want your confirmation that the message contents are correct (data, addr, cid, cmd, and crc are all as they should be), and that the sequencing of messages are correct, and that I should at the very least be able to receive some level of response from the chip.

I am trying to understand if the third-party/off-the-shelf system I am working with is not working or if I am just not sending the right data.

Re: MC33664 and MC33772B Communication Issues

guoweisun — Fri, 21 Mar 2025 15:53:56 GMT

Did you refer to attached code for CRC calculation?