2024-04-05 02:59 PM - edited 2024-04-05 03:01 PM
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(ð_handle_, &ptp_config));
SET_BIT(eth_handle_.Instance->MACPOCR, ETH_MACPOCR_PTOEN);
Solved! Go to Solution.
2024-07-08 04:55 AM - edited 2024-08-19 07:16 AM
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
Solved: STM32F7 PTP Support - STMicroelectronics Community
you can also refer to the implementation in these GitHub repos:
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:
Program the 80-bit Source Port Identity:
Match with Ingress PTP Messages:
Use in Egress PTP Messages:
To answer your specific questions:
If your Source Port Identity is 0x123456789ABCDEF01234
, you would program the registers as follows:
0xDEF01234
0x56789ABC
0x1234
more on that in RM0468 page 2927 and onwards.
Regards
2024-07-08 04:55 AM - edited 2024-08-19 07:16 AM
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
Solved: STM32F7 PTP Support - STMicroelectronics Community
you can also refer to the implementation in these GitHub repos:
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:
Program the 80-bit Source Port Identity:
Match with Ingress PTP Messages:
Use in Egress PTP Messages:
To answer your specific questions:
If your Source Port Identity is 0x123456789ABCDEF01234
, you would program the registers as follows:
0xDEF01234
0x56789ABC
0x1234
more on that in RM0468 page 2927 and onwards.
Regards