search

mpthompson / stm32_f4_ptpd

IEEE 1588 PTP daemon for STM32 F4 Discovery board
73 stars 59 forks source link

Some questions in reading the code #3

Open TerryLv opened 7 years ago

TerryLv commented 7 years ago

Hi,

I'm trying to porting ptpd to NXP Kinetis K64 board. I read the code and have a question. Can you kindly help me?

Thank you in advance.

In code, updateClock() in servo.c, it will calculate the time and set it to system time. getTime(&timeTmp); subTime(&timeTmp, &timeTmp, &ptpClock->currentDS.offsetFromMaster); setTime(&timeTmp); and in sys_time.c, setTime function will call ETH_PTPTime_SetTime to set time to PTPTSHUR and PTPTSLUR register. But PTPTSHUR and PTPTSLUR are update register. The value will be added or subtracted from system time.

Isn't setTime function will set time directly to system time? Or, timeTmp from subTime(&timeTmp, &timeTmp, &ptpClock->currentDS.offsetFromMaster); is just a relative time value?

mike-at-ologic commented 7 years ago

It's been a number of years since I looked at this code, but I'll try to help. Looking over the code in question and the STM32F4 datasheet, the PTPTSHUR and PTPTSLUR registers are described as follows:

"This register (PTPTSHUR) contains the most significant (higher) 32 bits of the time to be written to, added to, or subtracted from the System Time value. The Time stamp high update register, along with the Time stamp update low register, initializes or updates the system time maintained by the MAC. You have to write both of these registers before setting the TSSTI or TSSTU bits in the Time stamp control register."

In this case, setTime() calls ETH_PTPTime_SetTime() which sets the PTPTSHUR and the PTPTSLUR registers and then calls ETH_InitializePTPTimeStamp() which overwrites the system clock from these two registers by setting the TSSTI bit rather than the TSSTU bit which would add or subtract these registers from the system time.

Therefore, as far as I can tell, the setTime() function will set the system clock directly to the values specified. timeTmp is not a relative value, it is the actual system time to be set (which is minus the offset from master).

Hopefully this answers your question.

TerryLv commented 7 years ago

Thank you very much!

TerryLv commented 7 years ago

Hi Mike,

As latest version of ptpd is 2.3.1 now, is there any plan to upgrade ptpd to latest in this project?

Thank you!

Regards Terry

mike-at-ologic commented 7 years ago

I'm not planning on updating the code at this time. I did this work as a consultant for a company a few years ago and they generously let me open source this work to share it with others. However, I would be happy to take any pull requests that improve the code, or please feel free to branch the code and include the newer ptpd into it.

TerryLv commented 7 years ago

Hi Mike,

Thank you very much for your answer.

My work is still on-going. I've another question for this project.

Can you help me?

In function ptpd_thread() in ptpd.c, I see that rtOpts.slaveOnly is set to SLAVE_ONLY. Does this mean that in this project, the stm32 chip can only be a slave clock?

Thank you!

Regards Terry

TerryLv commented 7 years ago

Hi Make,

One more question.

When I first ran the ptpd application. The code will get asserted when calling ptpd_thread->doState->doInit->netShutdown->igmp_leavegroup. Asserted in the code:

LWIP_ERROR("igmp_leavegroup: attempt to leave non-multicast address", ip4_addr_ismulticast(groupaddr), return ERR_VAL;);

The code was checking if ptpClock->netpath.multicastAddr is a multicast address.

I searched in code and found that value of netpath.multicastAddr is set in netInit function, after calling netShutdown().

Though I thought ptpClock->netpath.multicastAddr should be initilized to a multicase address somewhere, I couldn't find where it is initilized.

Can you kindly tell me if ptpClock->netpath.multicastAddr should be initilized to a multicase address and where it is initilized to pass the LWIP_ERROR assert?

Thank you very much!

Regards Terry