The current DEMO routine for MC33665+MC33774 implements 665 initialization, 774 initialization, and voltage and temperature acquisition functions. The bench setup is shown in the figure. 1.
When the S32K314 main control unit uses JLINK to connect to the SWD debug port for debugging and simulation, both 33774 and 33665 can respond normally, returning reply frames and acquiring the correct unit voltage and GPIO port data. The bench power-on sequence is "sampling slave board power-on -> MC33665A power-on -> MCU main board power-on". The communication initialization to request read register message is shown as MC33774_FIRST (where the CAN type message is the MC33665 reply frame). 2. When the emulator is disconnected and the entire bench is powered down, wait for a period of time, and then power on again in the sequence of "sampling slave board power-on -> MC33665A power-on -> MCU main board power-on", the MC33774 does not respond, and only the MC33665A can return a response frame. Re-initializing the MCU motherboard by powering it on and off didn't work; it only communicates normally with the MC33774 when debugging with J-Link. The message is as shown in MC33774_SECOND. I'd like to know what directions I can take for troubleshooting.
当前MC33665+MC33774的DEMO例程实现665初始化、774初始化以及电压温度采集功能，台架构成如图：
1.当S32K314主控部分使用JLINK链接SWD调试口进行调试仿真时，33774和33665均能正常响应返回回复帧并且采集正确的单体电压和GPIO端口数据。台架上电顺序为“采样从板上电->MC33665A上电->MCU主板上电”。通讯初始化至请求读取寄存器报文如MC33774_FIRST所示（其中CAN 类型的报文为MC33665回复帧）
2.当断开仿真器并且将台架全部下电后等待一段时间，重新按照“采样从板上电->MC33665A上电->MCU主板上电”顺序上电后，MC33774无响应，仅有MC33665A能返回响应帧。重新将MCU主板上下电进行初始化也无效，只有用JLINK调试时又能正常与MC33774通讯。报文如MC33774_SECOND所示。
我想知道有什么排查的方向吗？
Dear Embedded Novice,
- The MC33665 includes internal communication management and does not behave as a transparent bridge.
- When the MC33665 is reset while the MC33774 remains powered, the TPL link becomes unsynchronized, leaving the device in a state where SPI communication works but TPL forwarding is not enabled.
- Executing initialization twice effectively clears the internal state and re-establishes link synchronization, which is why it resolves the issue.
- The recommended solution is to ensure proper TPL re-initialization or synchronized reset of both devices.
With Best Regards,
Jozef
Through experimentation, I discovered that the issue is caused by the MC33665 being powered off. When my MC33774 remains powered on, and the MC33665 powers off and restarts, and the MCU also powers off and restarts, although the software logic reinitializes the MC33665, it seems to be in a state where it cannot forward TPL data. This is because my messages show that the MC33665 can send reply frames. Therefore, the MC33665 must be in some state that prevents it from converting the TPL signal and sending it to the 33774. Currently, I can avoid this phenomenon by performing the same MC33665 initialization twice in the software logic. However, I am unclear why the MC33665 behaves this way. Do you have any ideas?
我通过实验发现是由于MC33665下电导致的，当我的MC33774保持上电，MC33665下电重启，MCU也下电重启后，虽然软件逻辑上会对MC33665重新初始化，但是此时MC33665似乎处于无法转发TPL数据的状态，因为我的报文中可以看出MC33665能够发出回复帧，所以MC33665应该处于某种状态导致无法转换TPL信号并发送给33774。我当前是在软件逻辑中进行两次相同的MC33665初始化就能够避免这种现象。但是我并不清楚MC33665为什么会这样。请问您有什么思路吗？
Dear Embedded Novice,
The issue is most likely caused by a startup timing dependency. When the system is debugged with J‑Link, the MCU execution is delayed, giving sufficient time for the MC33774 to complete its internal initialization. In a normal power-up scenario, the MCU starts immediately and sends communication requests before the MC33774 is ready, resulting in no response.
It is recommended to introduce a delay (e.g., 50–200 ms) before the first communication, implement a retry mechanism, and ensure that the MC33665 correctly initializes and wakes up the TPL communication chain before addressing the MC33774. Additionally, the reset and power ramp conditions of the MC33774 should be verified.
With Best Regards,
Jozef