S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restriction Product / environment Device: S32K396 (S32K39/37/36 family), eTPU singleinstance, dual engine Reference: S32K39, S32K37 and S32K36 Reference Manual,Rev. 4, 11/2024, chapter 67 (eTPU) SDK: S32 Design Studio 3.6.10, RTD 6.0.0, ETpu_Ip /Etpu_Pwmm_Ip drivers Board: S32K396BMS-EVB, 176 LQFP Phenomenon reproduced by writing the eTPU time-baseregisters directly at run time (register addresses and values only, no application code involved). What the manual says RM 67.3.8.3 "STAC interface": "Both time bases TCR1 andTCR2 can be shared between the Engines and with other blocks in the same MCU... TCR1: Can be exportedto or imported from the bus." RM 67.3.8.1.5: "STAC Bus Server mode - TCR1 bus can beexported to the bus as a server." RM Table 378 (chip-specific): engine 1 TCR1 = server ID 0,engine 2 TCR1 = server ID 1. So TCR1 server/client operation is expected to work on thisdevice. What works (baseline, 20 MHz shared time base) Engine 1 exports TCR2 (server ID 2), engine 2 imports it as itsTCR1: STAC_ENG1 (0x4068002C) = 0x8002C200 (REN2=1, RSC2=1server; REN1=1, RSC1=0 client of ID 2) STAC_ENG2 (0x4068004C) = 0x81020300 (REN1=1, RSC1=0client, SRV1=2) TB1R_ENG1 and TB1R_ENG2 track each other; thisconfiguration runs a 9-phase PWM correctly. What fails (TCR1 as the shared resource) - tried in bothdirections Sequence used, per the NOTE in STAC_ENGn: "RSC1 mustnot be changed when the REN1 bit is asserted", so REN1 was cleared first, then RSC1/SRV1 written, thenREN1 set again. The client engine was also tested with TBCR[TCR1CTL]=11("TCR1 frozen, except as a STAC client"). (a) Engine 1 server, engine 2 client TBCR_ENG1 (0x40680020) = 0x8000A000 (TCR2CTL=100DIV8; TCR1CTL=10, TCR1CS=1 = eTPU clock) TBCR_ENG2 (0x40680040) = 0x8000C000 (client,TCR1CTL=11 frozen) STAC_ENG1 = 0xC002C200 (REN1=1, RSC1=1 server,SERVER_ID1 reads 0) STAC_ENG2 = 0x81000300 (REN1=1, RSC1=0 client,SRV1=0) Result: TB1R_ENG1 keeps counting, TB1R_ENG2 freezes at itscurrent value (1989303) and does not change over 400 ms of observation. (b) Engine 2 server, engine 1 client STAC_ENG2 = 0xC1020300 (REN1=1, RSC1=1 server,SERVER_ID1 reads 1) STAC_ENG1 = 0x8001C200 (REN1=1, RSC1=0 client,SRV1=1) Result: TB1R_ENG1 freezes at 1769497, TB1R_ENG2 keepscounting. Readback of STAC_ENGn confirmed every bit took effect(REN/RSC/SRV/SERVER_ID as written), MCR[GTBE] was asserted, both engines were out of Angle Mode (AM=0)and no engine was configured as a client of itself. Questions 1. Does the S32K396 system-integration STAC controllerallocate time slots for the eTPU TCR1 resources (server IDs 0 and 1)? RM 67.3.8.3 states the eTPUhas no Controller module and that it is "instantiated once in the system integration", but theS32K396 RM does not document that controller. 2. If TCR1 export is supported on this device, what is themissing configuration step - is there a system-integration register, a PCMC/clock-control setting,or a Peripherals-tool option that has to be enabled for the TCR1 time slot to be driven on the RedLine? 3. If TCR1 export is NOT supported on S32K396, pleasedocument the restriction (RM errata or a note in the eTPU chapter), because the current wording implies itworks. Why it matters The 20 MHz STAC time base is the only way currentlyavailable to guarantee that both eTPU engines count the same time base. It gives 50 ns PWM resolution, which isnot enough for current-loop duty control (12 bit at 20 kHz needs >= 8192 counts). Sharing TCR1 at 80or 160 MHz would solve that directly. As a fallback we are evaluating native TCR1 at 160 MHz(TCR1CTL=10, TCR1CS=1) with MCR[GTBE] start; RM 67.3.8.4 states that with TCR1CS=1 both engines' TCR1start together, which would also be acceptable if confirmed. Related public information NXP Community, "STAC Interface" (MPC5xxx, 2016), NXPTechSupport answer: https://community.nxp.com/t5/MPC5xxx/STAC-Interface/m-p/532642 It states that the STAC bus lets an eTPU export its timebase(TCR1/TCR2) to another eTPU as well as to peripherals such as eMIOS, that REDCR(eTPU_TBR_STAC_ENGx) is all that has to be programmed,and that with two engines there are "4 fixed time slots". On S32K396those four slots are exactly the server IDs of Table 378 (0/2 for engine 1, 1/3 for engine 2), so slots 0and 1 for TCR1 are expected to be live. This is why we would like to know whether the S32K396integration implements all four slots. Attachments on request: register dump sequence (gdbscript) that reproduces the freeze; no customer application code is involved. Re: S32K396 eTPU: TCR1 cannot be shared over theSTAC bus (TCR2 works) - please confirm the restricti
The STAC interface, also referred to as the Red Line, is present on S32K396. The successful sharing of TCR2 between the two eTPU engines confirms that the interface itself is operational.
Based on the current Reference Manual description and Table 378, TCR1 export through server IDs 0 and 1 appears to be supported. I am not aware of any additional PCMC, clock-control, system-integration, or Peripherals-tool configuration required to enable these STAC resources. The described programming sequence also appears to follow the requirement to clear REN1 before changing RSC1 and SRV1.
Since TCR2 sharing works while TCR1 sharing does not work in either direction, although the STAC register values read back as expected, I cannot currently identify an obvious configuration error. This requires clarification from the eTPU application team to determine whether there is an additional undocumented requirement, a restriction in the S32K396 integration, or a possible documentation or implementation issue. The provided GDB register-dump script can be used to review and reproduce the exact configuration sequence.
Regarding the fallback solution, MCR[GTBE] provides the documented mechanism for starting the engine time bases together. However, when each engine uses its own native TCR1 clock, the counters remain independent after the initial start. Therefore, the resulting synchronization accuracy and any possible long-term offset should be confirmed before this approach is used for the final current-loop PWM implementation.
記事全体を表示
