Some questions in reading the code
TerryLv opened this issue · 6 comments
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?
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.
Thank you very much!
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
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.
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
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