S32K344 RTD 3.0.0: empty .slewRateCtrlSel generated for LPSPI4 pins — build fails

[hyunsiksong]

Hello,

I am bringing up a battery-management application on an S32K344 (172-pin MQFP) custom board whose SPI wiring follows the NXP RD33772C14EVM reference design. I am using S32 Design Studio 3.5 with RTD 3.0.0 (the Platform, Port and Spi modules all report SW version 3.0.0) and the FS26 SBC CDD 2.0.0 (Sbc_fs26). My starting point is the Sbc_fs26_example_HLD example for S32K344.

In my system LPSPI0 is reserved for a future two-channel daisy-chain and the other SPI instances are already in use, so the FS26 SBC has to run on LPSPI4. Following the RD33772C14EVM schematic, I routed the four LPSPI4 signals to the same pads the reference design uses: lpspi4_pcs0 on PTB8, lpspi4_sout on PTB9, lpspi4_sck on PTB10 and lpspi4_sin on PTB11. On the peripheral side I set the SPI physical-unit mapping to LPSPI_4, left SpiHwUnit at CSIB0, and enabled the LPSPI_4 peripheral-clock gate in the Mcu component.

After running "Update Code" and building, the compiler stops with errors in the generated file generate/src/Siul2_Port_Ip_VS_0_PBcfg.c. The generator has produced an assignment with no right-hand side:

../generate/src/Siul2_Port_Ip_VS_0_PBcfg.c:118:34: error: expected expression before ',' token
118 | .slewRateCtrlSel = ,

The same empty .slewRateCtrlSel = , appears at lines 158, 198 and 238 — one for each of the four LPSPI4 pins. If I manually fill those four lines with PORT_SLEW_RATE_NOT_AVAILABLE, the build gets a little further and then fails the same way on .inputMuxReg = { (empty initializer, "ISO C forbids empty initializer braces"). In other words, the pin-configuration structures for these four pads are generated with empty fields that are not valid C.

When I look at the Pins tool "Routing Details" for PTB8–PTB11, the Slew Rate Control column (and the Input Filter column) shows n/a, and selecting the Slew Rate cell shows the tooltip: "The selected pin does not support the configuration of this feature. Selects the slew rate control." So these particular pads simply have no slew-rate-control hardware. My understanding is that in that case the generator should emit PORT_SLEW_RATE_NOT_AVAILABLE (that value does exist in the Siul2_Port_Ip_PortSlewRateControl enum on this device), the same way it uses *_NOT_AVAILABLE values for other unsupported pad features — but instead it emits nothing, which breaks the build.

What convinces me this is a tool/driver problem rather than a wrong pin choice is that NXP's own LVBMS_RD_Bring_up_Example uses the exact same four LPSPI4 pads (PTB8/PTB9/PTB10/PTB11) for the FS26 SBC and builds cleanly. The only difference I can find between that example and my project is the RTD version: the LVBMS example is built on RTD 2.0.0 (Platform/Port/Spi SW 2.0.0), while my project uses RTD 3.0.0. Same board pinout, same four pins, and the pin electrical features are identical (only direction is set in both). So it really looks like the Siul2_Port_Ip code generation for slew-rate-unsupported pads regressed between RTD 2.0.0 and RTD 3.0.0.

My questions:

Is this a known issue in RTD 3.0.0, and is there a fixed / patched RTD release?
What is the correct, supported way to configure LPSPI4 on PTB8–PTB11 (the RD33772C14EVM pinout) under RTD 3.0.0 so that the Pins tool generates valid code — i.e. slewRateCtrlSel = PORT_SLEW_RATE_NOT_AVAILABLE and a valid inputMuxReg, instead of empty fields?
If there is no configuration-level fix, is editing the generated Siul2_Port_Ip_VS_0_PBcfg.c by hand the only workaround (it is overwritten on every "Update Code"), or is moving the project to Port/RTD 2.0.0 the recommended path?

I can attach the full build log, the Pins "Routing Details" screenshot with the tooltip, and a side-by-side of the two projects' module versions if that helps.

Thank you,
Hyunsik Song

[VaneB · Accepted solution]

Hi @hyunsiksong 

This issue is not related to the RTD itself, nor with the code generated by the S32DS Configuration Tools. Instead, it is related to the configurations.

In the Port driver configuration within the Peripheral Tool, the values assigned to the PortPin Mscr parameters still correspond to the original project configuration. For example, the project was previously configured to use PTB1 as LPSPI0_PCS0, corresponds to PortPin Mscr = 33.

In the updated configuration, however, LPSPI4 is being used and PCS0 has been reassigned to pin 8. Therefore, the corresponding PortPin Mscr value should be 40 instead of 33.

Review the PortPin Mscr for all the pins and ensure they match the current pin assignments Updating these values to reflect the new configuration should resolve the issue.

BR, VaneB

[hyunsiksong]

Hi VaneB,

Thank you very much — that was exactly the problem. The Pins tool had been updated to LPSPI4 (PTB8–PTB11), but the Port component's PortPin entries were still pointing at the original LPSPI0 pads, so the PortPin Pcr (Mscr) values were stale.

I updated the four PortPin Pcr values in the Port configuration to match the new pin assignment:

• PCS0 → PTB8 (Pcr 40)
• SOUT → PTB9 (Pcr 41)
• SCK → PTB10 (Pcr 42)
• SIN → PTB11 (Pcr 43)

After running Update Code and rebuilding, the empty .slewRateCtrlSel / .inputMuxReg errors in Siul2_Port_Ip_VS_0_PBcfg.c are gone and the project builds cleanly.

I really appreciate the quick and precise answer — it saved me a lot of time. Marking this as the solution.

Best regards,
Hyunsik