NUCLEO-H7S3L8 | ETH Register Problem - MACTSCR Bit 5 Stays SET (IEEE 1588 Timestamping)

[Fatih_Yildirim]

I'm working on implementing Precision Time Protocol (PTP) on the STM32H7S3L8 Nucleo board. I have followed the steps outlined in section 64.9.9 Programming Guidelines for IEEE 1588 Timestamping from the reference manual. (github: stm32h7_ptpd) 

 

/* Mask the timestamp trigger interrupt */
 ETH->MACIER &= ~(ETH_MACIER_TSIE);
/* Program the Subsecond increment register based on the PTP clock frequency. */
	ETH_SetPTPSubSecondIncrement(ADJ_FREQ_BASE_INCREMENT); /* to achieve 20 ns accuracy, the value is ~ 43 */

	if (UpdateMethod == ETH_PTP_FineUpdate)
	{
		/* If you are using the Fine correction method, program the Time stamp addend register
	 * and set Time stamp control register bit 5 (addend register update). */
	 ETH_SetPTPTimeStampAddend(ADJ_FREQ_BASE_ADDEND);
	 ETH_EnablePTPTimeStampAddend();

	 /* Poll the Time stamp control register until bit 5 is cleared. */
	 while(ETH_GetPTPFlagStatus(ETH_PTP_FLAG_TSARU) == SET);
	}

	/* To select the Fine correction method (if required),
	 * program Time stamp control register bit 1. */
	ETH_PTPUpdateMethodConfig(UpdateMethod);

	/* Program the Time stamp high update and Time stamp low update registers
	 * with the appropriate time value. */
	ETH_SetPTPTimeStampUpdate(ETH_PTP_PositiveTime, 0, 0);

	/* Set Time stamp control register bit 2 (Time stamp init). */
	ETH_InitializePTPTimeStamp();

	/* Set PPS frequency to 128 Hz */
	ETH_PTPSetPPSFreq(7);

 

 

However, I'm facing an issue at step 5 (line 14), which states: "Poll the Timestamp Control Register (ETH_MACTSCR) until bit 5 is cleared." In my case, the 5th bit of the ETH_MACTSCR register remains SET indefinitely and does not clear as expected. But the exact same code works fine on STM32H743 Nucleo board.

• Has anyone encountered a similar issue with the ETH_MACTSCR register on the STM32H7S3L8?
• Are there any known workarounds or additional steps that I might be missing to ensure this bit clears properly?
• Could there be a hardware-specific issue or a potential bug in the microcontroller that I should be aware of?

@STea  @LCE  @nouirakh 

[STea]

Hello @Fatih_Yildirim ,

I will try to reproduce the behavior you're describing on H7s and come back to you soon.

Regards

[LCE]

No problems here on H735.

Here's my PTP start:

/* 1. Mask the time stamp trigger interrupt */
	ETH->MACIER &= ~ETH_MACIER_TSIE;
	/* reset interrupt flag */
	u8PtpTargetIrqFlag = 0;

/* 2. Program time stamp register bit 0 to enable time stamping. */
 /* Enable the PTP time stamp for transmit and receive frames, IPv4, IPv6, PTPv2 */
	u32TempReg = ( 	ETH_MACTSCR_TSENA | ETH_MACTSCR_TSVER2ENA |
					ETH_MACTSCR_TSIPV4ENA |	ETH_MACTSCR_TSIPV6ENA |
					ETH_MACTSCR_TSENALL );

	ETH->MACTSCR = u32TempReg;

	if( u8PtpUpdate == PTP_UPDATE_FINE )
	{
/* 5. Poll the time stamp control register until bit 5 is cleared. */
		u8RetVal = PTP_PollCSBitClear(ETH_MACTSCR_TSADDREG, PTP_TIMEOUT_MS_TSADDREG);
		if( u8RetVal ) Error_Handler_FL(__FILE__, __LINE__);

/* 6. To select the fine correction method program time stamp control register bit 1. */
		ETH->MACTSCR |= ETH_MACTSCR_TSCFUPDT;
	}
	else
	{
		ETH->MACTSCR &= ~ETH_MACTSCR_TSCFUPDT;
	}
	/* rollover bit TSCTRLSSR selects between full nanoseconds and sub ns
	 *	-> MUST use sub nano, otherwise PPS output is useless
	 *	-> NOT set
	 */
	ETH->MACTSCR &= ~ETH_MACTSCR_TSCTRLSSR;

/* 3. Program the sub-second increment register based on the PTP clock frequency. */
/* 4. Program the time stamp addend register and set time stamp control register bit 5
 * (addend register update).
 */
	u8RetVal = PTP_CalcIncrAdnd((float)dflPTP_ClkRef_Hz);
	if( u8RetVal ) Error_Handler_FL(__FILE__, __LINE__);
	u32PtpAddendStart = u32PtpAddend;

/* 7. Program the time stamp high update and time stamp low update registers with the
 * appropriate time value. (can be zero)
 */
	/* Reset Time stamp high update and Time stamp low update registers */
	ETH_SetPtpTimeStampUpdate(ETH_PTP_PositiveTime, 0, 0);

/* 8. Set time stamp control register bit 2 (time stamp init). */
	u8RetVal = PTP_CtrlBit_Update(ETH_MACTSCR_TSINIT, PTP_TIMEOUT_MS_CTRLBU);
	if( u8RetVal ) Error_Handler_FL(__FILE__, __LINE__);

/* 9. The time stamp counter starts operation as soon as it is initialized with the value written
 * 		in the time stamp update register.
 */

/* 10. Enable the MAC receiver and transmitter for proper time stamping. */
/* -> ethernetif.c EthLowLevelInit() */

	/* set PPS output (PB5, set in ethernetif.c) to default frequency */
	ETH->MACPPSCR = PTP_PPS_OUT_FDEF;

/* set ingress (RX) & egress (TX) correction registers,
 *	fixed offsets depending on PHY
 *	ingress value must be negative, depends on TSCTRLSSR
 *	NOTE: absolutely useless... or wrong?
 */
#if( 0 )
	float flVal = (float)PTP_H7_RX_CORRECT_DEF / (float)PTP_SUBSEC_REG_RES_NS;
	u32TempReg = 0x8000000;			// 2^31;
	u32TempReg -= (uint32_t)flVal;
	u32TempReg |= 0x80000000;
	ETH->MACTSICNR = u32TempReg;
	ETH->MACTSECNR = PTP_H7_TX_CORRECT_DEF;
#else
	ETH->MACTSICNR = 0;
	ETH->MACTSECNR = 0;
#endif

 

[Fatih_Yildirim]

I'm waiting your response, thanks for your attention. @STea 

[STea]

Hello @Fatih_Yildirim ,

After verifying this indeed the same code is hanging on step5, but this is explained by the change of architecture for the Ethernet clock source especially. here is why:

in H747 the clock source for PTP is the HCLK so no problems there it should work without any hustle

in H7s the kernel clock distribution changed and the source for ptp_ref_clk is pll1_s_ck

so, for this to work properly you need to enable the pll1_s_ck by setting bit 8 of RCC PLL1DIVR2 register 

by default, the value should be vco1_ck/2 and it's up to you to set you clock to the desired value

these snippets where extracted form RM0477 for H7sxx and RM0433 for H74xx MCUs.

Regards

[Fatih_Yildirim]

Thank you for your detailed explanation and for verifying the issue. Your insights into the changes in the Ethernet clock source architecture are very helpful, now I'm able to run my PTP code on STM32H7S3L8 Nucleo board.

I suggest adding this solution to the section 64.9.9 Programming Guidelines for IEEE 1588 Timestamping. This addition would greatly benefit others who might encounter a similar issue.

Thanks again for your valuable input!