STM32N6 CSI-2: No frame lock

[edenraf]

Hello,

Has anyone seen ACTCLF permanently stuck at 0 on STM32N6 despite a confirmed HS clock at the input?

I have had issues with this for some time and need a little help. Pehraps the following questions could be enligtning.

1. Are there SNPS D-PHY initialization or calibration steps for the clock lane beyond what HAL_DCMIPP_CSI_SetConfig performs? Clock-lane equivalents of the 0xe2–0xe4 DDL registers?
2. Can ST confirm the CSI kernel clock (IC18) is the D-PHY cfg_clk, and its required range? The CCFR encoding caps at ~33 MHz and the DK example uses 20 MHz, but we couldn't find this constraint stated in RM0486.
3. Is PTSR being permanently 0 expected on this silicon? Is there any way to verify test-interface writes landed?
4. What exactly are the conditions for ACTCLF to assert? Does the RX require observing a complete LP-11 to LP-01 to LP-00 entry sequence after PEN, and is there a known failure mode if the LP levels at the pad are degraded (e.g., loaded by an external common-mode filter) while HS amplitude is fine?
5. Any relevant errata for the CSI D-PHY on STM32N657?

Lots of questions, I know. Its just all I can think of to find a solution. Extra info below.

 

Hardware: STM32N657X0HxQ + Sony 12MP image sensor, 1-lane CSI-2, 1188 Mbps (27 MHz INCK * 44), continuous HS clock mode.

Problem:

• The D-PHY clock CDR never acquires.
• CSI_SR1.ACTCLF (bit31) = 0 in every run across many changes/improves.
• SOF0F always 0.
• ERR1/ERR2 OR-accumulated are 0x00. No error bits of any kind: total silence.

What IS working (verified):

• Sensor streaming confirmed by I2C readback and oscilloscope at the sensor.
• HS clock physically reaches the STM32N6 pads
• Intra-pair skew measured at 3-7 ps vs the 126 ps budget
• ULPS is fine

Thanks!!

 

[db16122]

ACTCLF: D-PHY_RX receiver clock active flag This bit indicates the status of RxClkactiveHs D-PHY_RX signal.

If this bit stuck, it means your receiver clock is not activatived. Do you have any waveform to share?

[edenraf]

Please find three oscilloscope captures attached, all measured at the STM32N6 CSI input pads (after a ECMF240A100N6 common-mode filter). Note that our oscilloscope is only 1.5GHz.

scope_6: Wide view at 1 ms/div showing the periodic HS burst structure. LP-11 idle regions and continuous HS clock activity are visible.

scope_11: LP -> HS entry sequence at 50 ns/div. Left side shows LP-11 at approximately 1.09 V per line. The LP-01 intermediate state is visible (CK_P drops first), followed by LP-00, then HS burst onset. This sequence is arriving intact at the MCU pad.

scope_12: Same LP -> HS entry at 200 ns/div showing fuller context. LP-11 stable region on the left, full transition sequence in the middle, HS burst settling on the right.

Summary of measured values at the STM32N6 pad:
    •    LP-11: CK_P = 1.106 V, CK_N = 1.111 V
    •    HS common mode: approximately 190 mV
    •    HS differential amplitude: approximately 140 mVpp
    •    LP -> HS entry sequence: complete and intact, LP-01 step visible

The signal integrity at the MCU pad is confirmed. Given this, we are confident the issue is not in the physical signal path. The question remains why the SNPS D-PHY clock CDR does not respond to this input.

Can you confirm whether there are any known initialisation requirements specific to the ONE_DATA_LANE + INVERTED_DATA_LANES configuration, or any relevant errata for the CSI D-PHY on STM32N657?

[edenraf]

I sent a message with scope images a few minutes ago. I received an error when sending it. Please confirm you received it here 

[db16122]

Please refer to AN6211 for CSI bus information, Is there error log information reported from MCU side?

[edenraf]

Thank you for the reply.
We have read AN6211 in full. However It covers DCMIPP pipeline architecture and pixel formats well, but does not include D-PHY register-level initialization sequences. Our question relates more to whether any clock-lane CDR initialization steps exist beyond what HAL_DCMIPP_CSI_SetConfig performs which AN6211 does not contain.

Error log from MCU side:
The symptom is conspicuous absence of errors. Over a 2-second accumulation window after streaming starts:

- CSI_ER1 OR-accumulation: 0x00

- CSI_ER2 OR-accumulation: 0x00

- CSI_SR1 steady state: 0x76101000: ULPNCLF, ULPNACTF, ULPNDL1F, ULPNDL0F all set (lanes not in ULPS); STOPCLF=0 (HS clock present); ACTCLF=0 (CDR never locks)

- SOF0F: never set

- Zero short packets received, zero bytes of HS data decoded

Hardware is fully scope-verified at the STM32N6 pads: CK_P/CK_N/DL1_P/DL1_N all show correct LP-11 (~1.1V), LP -> HS entry sequence arrives intact, HS VCM ~190mV, differential amplitude above V_ID_min. The D-PHY is electrically seeing a valid 1188 Mbps clock.

[db16122]

Maybe you can using CSI-2 bring-up checklist

1. Check all supply voltages.

2. Make sure that I2C communication is functional:

• Verify the ability to send and receive data. One can use Linux I2C commands, such as, i2cdetect, i2cdump, i2cget, i2cset.

3. Make sure that sensor initialization registers are correct.

4. Check Camera and SOC MIPI clocks: a. Camera MIPI HS Bit clock, Pixel Clock, and Escape clock. b. SOC Pixel Clock and Escape Clock.

5. Check MIPI low-power communication, low frequency, and non-differential (Scope or MIPI analyzer).

6. Check MIPI high-speed communication, high frequency, and differential (MIPI Analyzer).

7. Check MIPI status register, such as: a. ECC and CRC Error Status Register b. IRQ Status Register c. ErrSot HS Status Register d. ErrSotSync HS Status Register e. ErrEsc Status Register f. ErrSyncEsc Status Register g. ErrControl Status Register

[edenraf]

Turns out I forgot to enable the CSI global interrupt and RIF enable for DCMIPP I get frame lock. Now it works fine

[db16122]

congratulations anyway since the waveform capture is pretty nice

[daniel196]

Check your LP levels right at the STM32 pads — a common-mode choke killed ours.