cancel
Showing results for 
Search instead for 
Did you mean: 

STM32H723 - Enabling IEEE 1588 PTP Offload does not transmit packets?

imran_khan
Associate

Hi!

I'm using an STM32H723ZG with the STM32 HAL. Ethernet is enabled (and LWIP is correctly configured and working fine). 

I'm trying to get the STM32's MAC to automatically reply to PTP SYNC messages using the PTP Offload feature. 

I've configured the MAC using the HAL_ETH_PTP_SetConfig function and then manually set the MAC's MACPOCR POEN bit, however no packets are produced. 

I'm trying to configure the STM32 to be an Ordinary Slave Clock so that it responds to SYNC messages. 

SYNC messages are correctly being sent on the network by my Master Clock (a linux workstation) however they are not causing the ethernet MAC on the STM to respond. 

I have several questions. 

What should I program the MACSPI0R, MACSPI1R and MACSP2R registers to? Should it be programmed to the Clock ID of my Master clock? Should it be a unique ID for the slave clock? 
PTP is configured with the following structure:
(The eth_hclk is at 260 Mhz)


ETH_PTP_ConfigTypeDef ptp_config{
.Timestamp = 0, /*!< Enable Timestamp */
.TimestampUpdateMode = 1, /*!< Fine or Coarse Timestamp Update */
.TimestampInitialize = 0, /*!< Initialize Timestamp */ // Does nothing
.TimestampUpdate = 1, /*!< Timestamp Update */
.TimestampAddendUpdate = 1, /*!< Timestamp Addend Update */
.TimestampAll = 1, /*!< Enable Timestamp for All Packets */
.TimestampRolloverMode = 1, /*!< Timestamp Digital or Binary Rollover Control */
.TimestampV2 = 1, /*!< Enable PTP Packet Processing for Version 2 Format */
.TimestampEthernet = 1, /*!< Enable Processing of PTP over Ethernet Packets */
.TimestampIPv6 = 0, /*!< Enable Processing of PTP Packets Sent over IPv6-UDP*/
.TimestampIPv4 = 0, /*!< Enable Processing of PTP Packets Sent over IPv4-UDP*/
.TimestampEvent = 1, /*!< Enable Timestamp Snapshot for Event Messages */
.TimestampMaster = 0, /*!< Enable Timestamp Snapshot for Event Messages */
.TimestampSnapshots = 0, /*!< Select PTP packets for Taking Snapshots*/
.TimestampFilter = 0, /*!< Enable MAC Address for PTP Packet Filtering */
.TimestampChecksumCorrection = 0,
/*!< Enable checksum correction during OST for PTP over UDP/IPv4 packets - not supported on this part???? */
.TimestampStatusMode = 0, /*!< Transmit Timestamp Status Mode */
.TimestampAddend = 886862695, /*!< Timestamp addend value */
.TimestampSubsecondInc = 40,
};

assert(HAL_OK == HAL_ETH_PTP_SetConfig(&eth_handle_, &ptp_config));
SET_BIT(eth_handle_.Instance->MACPOCR, ETH_MACPOCR_PTOEN);

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
STea
ST Employee

Hello @imran_khan ,

there are issues with the implementation of the HAL_ETH_PTP_SetConfig() which are tracked internally in ticket number 184159 (for internal reference only).

you can check the following related threads on the implementation of the PTP offload feature as the HAL for now does not offer support for the PTP protocol itself.

Solved: Re: NUCLEO-H7S3L8 | ETH Register Problem - MACTSCR... - STMicroelectronics Community

Getting started with PTP (IEEE 1588) - STMicroelectronics Community

STM32F427 PTP Implementation - STMicroelectronics Community 

Solved: STM32F7 PTP Support - STMicroelectronics Community

you can also refer to the implementation in these GitHub repos:

mpthompson/stm32_ptpd: Example PTPD slave and master projects for NUCLEO-F429ZI development boards. (github.com)

hasseb/stm32h7_atsame70_ptpd: IEEE 1588 PTP daemon for STM32H7 and ATSAME70 (github.com)

To answer your question about MACSPI0R, MACSPI1R and MACSP2R registers:

The MACSPI0R, MACSPI1R, and MACSPI2R registers should be programmed with the 80-bit Source Port Identity. This identity should match the ingress PTP (Precision Time Protocol) messages and be used in the egress PTP response messages. Specifically, these registers should be programmed to match the Source Port Identity of the ingress PTP Pdelay_Req message and send it in the egress PTP Pdelay_Resp message.

Here are the steps to program these registers:

  1. Program the 80-bit Source Port Identity:

    • ETH_MACSPI0R: This register holds the lower 32 bits of the Source Port Identity.
    • ETH_MACSPI1R: This register holds the middle 32 bits of the Source Port Identity.
    • ETH_MACSPI2R: This register holds the upper 16 bits of the Source Port Identity.
  2. Match with Ingress PTP Messages:

    • Ensure that the Source Port Identity programmed in these registers matches the Source Port Identity in the ingress PTP Pdelay_Req message. This is crucial for the correct operation of the PTP protocol.
  3. Use in Egress PTP Messages:

    • The programmed Source Port Identity will be used in the egress PTP Pdelay_Resp message.

To answer your specific questions:

  • Should it be programmed to the Clock ID of my Master clock?: No, it should match the Source Port Identity of the ingress PTP messages.
  • Should it be a unique ID for the slave clock?: Yes, it should be unique and match the Source Port Identity of the ingress PTP messages to ensure proper synchronization and communication.

Example

If your Source Port Identity is 0x123456789ABCDEF01234, you would program the registers as follows:

  • ETH_MACSPI0R: 0xDEF01234
  • ETH_MACSPI1R: 0x56789ABC
  • ETH_MACSPI2R: 0x1234

more on that in RM0468 page 2927 and onwards.

Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

1 REPLY 1
STea
ST Employee

Hello @imran_khan ,

there are issues with the implementation of the HAL_ETH_PTP_SetConfig() which are tracked internally in ticket number 184159 (for internal reference only).

you can check the following related threads on the implementation of the PTP offload feature as the HAL for now does not offer support for the PTP protocol itself.

Solved: Re: NUCLEO-H7S3L8 | ETH Register Problem - MACTSCR... - STMicroelectronics Community

Getting started with PTP (IEEE 1588) - STMicroelectronics Community

STM32F427 PTP Implementation - STMicroelectronics Community 

Solved: STM32F7 PTP Support - STMicroelectronics Community

you can also refer to the implementation in these GitHub repos:

mpthompson/stm32_ptpd: Example PTPD slave and master projects for NUCLEO-F429ZI development boards. (github.com)

hasseb/stm32h7_atsame70_ptpd: IEEE 1588 PTP daemon for STM32H7 and ATSAME70 (github.com)

To answer your question about MACSPI0R, MACSPI1R and MACSP2R registers:

The MACSPI0R, MACSPI1R, and MACSPI2R registers should be programmed with the 80-bit Source Port Identity. This identity should match the ingress PTP (Precision Time Protocol) messages and be used in the egress PTP response messages. Specifically, these registers should be programmed to match the Source Port Identity of the ingress PTP Pdelay_Req message and send it in the egress PTP Pdelay_Resp message.

Here are the steps to program these registers:

  1. Program the 80-bit Source Port Identity:

    • ETH_MACSPI0R: This register holds the lower 32 bits of the Source Port Identity.
    • ETH_MACSPI1R: This register holds the middle 32 bits of the Source Port Identity.
    • ETH_MACSPI2R: This register holds the upper 16 bits of the Source Port Identity.
  2. Match with Ingress PTP Messages:

    • Ensure that the Source Port Identity programmed in these registers matches the Source Port Identity in the ingress PTP Pdelay_Req message. This is crucial for the correct operation of the PTP protocol.
  3. Use in Egress PTP Messages:

    • The programmed Source Port Identity will be used in the egress PTP Pdelay_Resp message.

To answer your specific questions:

  • Should it be programmed to the Clock ID of my Master clock?: No, it should match the Source Port Identity of the ingress PTP messages.
  • Should it be a unique ID for the slave clock?: Yes, it should be unique and match the Source Port Identity of the ingress PTP messages to ensure proper synchronization and communication.

Example

If your Source Port Identity is 0x123456789ABCDEF01234, you would program the registers as follows:

  • ETH_MACSPI0R: 0xDEF01234
  • ETH_MACSPI1R: 0x56789ABC
  • ETH_MACSPI2R: 0x1234

more on that in RM0468 page 2927 and onwards.

Regards

In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.