topic Re: TPL Communication Timeout and Data Loss during Multi-Port Initialization (MC33665 + MC33774) in S32K

TPL Communication Timeout and Data Loss during Multi-Port Initialization (MC33665 + MC33774)

BillWen — Thu, 09 Apr 2026 01:41:42 GMT

Hi NXP Community,

I am currently migrating a Battery Management System (BMS) project from RTD 3.0 to RTD 6.0 on an S32K358 platform. While the exact same hardware and logic worked perfectly in RTD 3.0, I am encountering critical communication issues in RTD 6.0 when operating multiple TPL ports via the MC33665 Gateway.

Port 1: 1x BJB (MC33774)
Port 2: 3x CMUs (MC33774 in Daisy Chain)
Communication: SPI @ 8MHz, TPL @ 8MHz
OS: FreeRTOS

In RTD 6.0, the enumeration process fails immediately at the first device (BCC_Device_Addr = 1)，Bms_TD_Send(&TD_Cmu, &PhyError); return OK,
Td_Wait(&TD_Cmu); will cause PHY_TS_TIMEOUT (it should be PHY_TS_FINISHED), do you have any idea on it?

I attached our MC33774 initial function code, it's work on RTD3.0.0 but not on RTD6.0.0.

Btw, all of 33665 MCAL setting is the same with RTD3.0.0 one, please help us check.

Thanks
BR, BillWen

Re: TPL Communication Timeout and Data Loss during Multi-Port Initialization (MC33665 + MC33774)

BillWen — Fri, 10 Apr 2026 08:04:48 GMT

Hi :

I have some idea, maybe you can check this.

Environment:

S32K358, BMS GEN2 SDK 0.9.1, S32K3 RTD 6.0 (S32K3_RTD_6_0_0_D2506)

PHY: TPL33665, DUAL_SPI_MASTER_SLAVE, ICU sideband (EIRQ16)

BCC: MC33774A (TPL3 variable) + MC33772C (TPL2 fixed 48L)

RTOS: FreeRTOS

Previously working on RTD 3.0 (S32K3_RTD_3_0_0_P01_D2303)

Problem:
After migrating to RTD 6.0, all PHY TDs complete with PHY_TS_TIMEOUT instead of PHY_TS_FINISHED, even when valid response data is received (ResponseMsgNumAct > 0). The timeout handler also always reports PHY_NO_ERROR, making it impossible to distinguish successful transactions from real failures.

RTD 3.0 (correct): Successful → Status=FINISHED, PhyError=NO_ERROR | Failed → Status=TIMEOUT, PhyError=HW_ERROR
RTD 6.0 (buggy): Both cases → Status=TIMEOUT, PhyError=NO_ERROR

Root Cause (2 bugs in Phy_665a driver):

Race condition in IcuReqQueueLowNotification() — bRxExpectedFlag is cleared before DSpiRequestQueueLowIrq() is called. If SPI Slave RX fires in between, the response is ignored and SpiFinishStatusUpdate() is never called → GPT timeout always fires.

SpiTimeoutStatusUpdate() always called with PHY_NO_ERROR — even when no device responds. RTD 3.0 correctly reported PHY_HW_ERROR.

Workarounds applied:

Check ResponseMsgNumAct == 0 instead of Status == PHY_TS_FINISHED to detect real failures

Check only PhyError for write-only TDs

Split large multi-device TDs into per-device TDs to avoid GPT timeout truncation

Thanks

BR, BillWen

Re: TPL Communication Timeout and Data Loss during Multi-Port Initialization (MC33665 + MC33774)

PetrS — Fri, 10 Apr 2026 10:16:32 GMT

Hi,

To move this forward, I think it would help a lot if you could share a bit more concrete data:

Please specify the exact project you are migrating
Could you provide SPI bus measurements (logic analyzer or scope) for the failing case?
Ideally tied to the exact code path (e.g. which SPI API and configuration).
If possible, please capture the same SPI transaction on the RTD300-based project that is working and compare it against the new RTD.
Differences in CS timing, inter-frame gaps, clock behavior and missing frames could point directly to the root cause.

Side-by-side measurements between RTD300 and the new RTD would likely make the root cause very obvious.

BR, Petr