2025-08-27 8:45 AM - last edited on 2025-08-27 8:51 AM by Peter BENSCH
Title: SPC56 FlexRay stays in startup (CSAA=1, STARTUPSTATE=5) with TJA1080ATS – static segment only, two ECUs, can’t reach Normal Active
MCU / IP: SPC56ELxx family (FlexRay controller inside SoC)
Transceiver: NXP TJA1080ATS (Channel A only)
Network topology: 2 ECUs directly on Channel A (no star coupler), proper bus termination added per TJA1080A datasheet
Bitrate: 2.5 Mbit/s (gBit = 50 ns µT; MT ≈ 2 µs; 40000 µT per cycle)
Firmware: Both ECUs built from the same project; only Frame ID / Key Slot differ per ECU.
Bring up a small FlexRay cluster with two ECUs where both are configured as coldstart and sync capable (per FlexRay spec we plan for more nodes later). Each ECU transmits a static sync frame in its own key slot (Frame IDs differ). Static payload length is fixed and identical on all nodes.
Message buffers (RX filters):
MB[0] filters Frame ID = 1 (MBFIDR=1)
MB[1] filters Frame ID = 2 (MBFIDR=2)
MB[17] left as “all” / shadow config (MBFIDR=2047 etc.)
Key registers at runtime (examples):
PCR11.KEY_SLOT_USED_FOR_STARTUP=1, PCR11.KEY_SLOT_USED_FOR_SYNC=1
PCR18.KEY_SLOT_ID matches Frame ID per ECU (1 / 2 / 3 as tested)
PCR12.KEY_SLOT_HEADER_CRC prints as 1069 or 1586 depending on Frame ID (CRC code we compute is constant per header as expected)
PSR0.PROTSTATE=7, STARTUPSTATE=5, ERRMODE=0, SLOTMODE=2
PSR1.FRZ=0, CSAA=1, REMCSAT=1, CPN=0
PIFR1=0x1000, PIFR0=0x0001 (varies slightly between runs)
Debug outputs: CycleStart and SlotStart look correct; Syntax/Content error DBG pins show no pulses
On the scope, TXEN is controlled by the FlexRay peripheral and goes low before transmit; TJA1080ATS EN/BGE/STBN are held HIGH.
RXEN on TJA1080ATS is an indication output (not a control); we don’t drive it.
With proper termination fitted (per TJA1080A reference), the waveforms look clean.
Cycle timing: CycleStart and SlotStart spacing matches configuration (e.g., 100 µs between slot starts for gdStaticSlot=50).
Macrotick visibility on the debug pin: we observe ~1 µs pulses even though MT is configured as ~2 µs (gMacroPerCycle=1000 over 2 ms). The functional schedule timing (slots, cycle) still lines up with the config.
Frames transmitted by each ECU appear correct on the bus (header fields match, static payload length = 8 bytes).
Still, neither ECU reaches Normal Active. They remain with PROTSTATE=7 / STARTUPSTATE=5, CSAA=1, REMCSAT=1.
At some earlier point we had sum mismatch: static=800 sym=80 nit=113 -> sum=993 vs gMacroPerCycle=1000; this was corrected, and now the sums match (no current mismatch).
Verified all nodes share the same global timing (µT, MT, cycle, slot lengths, NIT, SW, APO).
Ensured identical static payload length across nodes (8 bytes = 4 words).
Confirmed unique key slots per ECU (PCR18) and both KEY_SLOT_USED_FOR_STARTUP/SYNC=1.
Checked Header CRC implementation (constant per header; matches between runs for fixed header).
Verified listen timeouts / noise parameters and increased pdAcceptedStartupRange to 1000 µT.
Confirmed bus termination per TJA1080ATS datasheet; verified clean signal edges; no obvious EMC issues.
Routed STBSCR DBG pins: CycleStart/SlotStart OK; Syntax/Content Error pins show no activity.
With two nodes both marked as coldstart & sync (key-slot frames in static segment), are our PCR11 / PCR18 settings sufficient, or is there any additional requirement on SPC56 FlexRay IP to allow mutual startup?
Does STARTUPSTATE=5 with CSAA=1 indicate we’re transmitting CASs but not receiving sufficient valid sync frames from the other node? If yes, which RX filters / acceptance settings must be enabled for the controller to consider the peer’s sync frame toward startup (beyond our MB[0]/MB[1] filters)?
Are there mandatory values or minimums for gdSymbolWindow, gdNIT, or gOffsetCorrectionStart on this IP to pass the startup state machine, beyond FlexRay spec nominal ranges?
Is any clock/debug pin selection (STBSCR.SEL) or internal clocking option required so that the controller can measure/qualify the peer’s frame timing during startup?
Is there a recommended way to confirm that our Header CRC as written into PCR12 is actually being used/accepted by the controller during CAS generation and validation?
Any gotchas for TJA1080ATS with SPC56: required pull-ups/downs, split termination, common-mode choke, or BGE/EN/STBN timing relative to controller reset that could keep the controller in startup?
Are we missing the configuration of SFIDRFR.SYNFRID (currently 0) or any other register that affects recognizing the peer’s sync frames during startup?
Any checklist to explain why DBG Syntax/Content error outputs are quiet while we still fail startup—does that imply the controller simply doesn’t see a valid peer frame at the expected place?
Any guidance or a minimal working example for this IP (two-node static-only cluster) would be greatly appreciated!