STM32F417. PTP protocol support. Programming error or defect of microcontroller?

[korrav]

Posted on February 20, 2013 at 16:40

I'm trying to implement support for PTP protocol based on microcontroller STM32F417. I had a problem.System timer PTP, an interrupt if the current time exceeds the value recorded in the registers Target time.This sets a flag in the register TSTS ETH_MACSR. This flag is cleared when the register is read ETH_MACSR. So says the Reference manual.However, in debug mode I saw that after reading TSTS flag register is not reset and the program gets stuck in an interrupt handler. So I put in interrupt handler loop, which again and again reads the contents of the register until ETH_MACSR TSTS flag is cleared.This works only in debug mode.When I run the program without the  programmer, it gets stuck in this loop forever.That is the flag TSTS not reset. Thank you!

#stm32 #ptp #ptp-stm32f407-eth_macsr-tsts #ptp #stm32f417

[Tesla DeLorean]

Posted on February 20, 2013 at 17:53

Sounds like you need to advance the target time so the condition doesn't persist.

[korrav]

Posted on February 21, 2013 at 03:59

[Tesla DeLorean]

Posted on February 21, 2013 at 06:01

It doesn't look unreasonable for the 107, are you using the ethernet library for a 4x7, like the one in the Ethernet IAP example?

[korrav]

Posted on March 04, 2013 at 15:34

Hello clive1! I use the ethernet library for a 4x7. I've made some changes to the ethernet driver to support ptp. At the same time I was guided on the example of 107. Ethernet works great! Ptpd protocol also operates.The only problem ptp timer. It can be considered  separately from the whole ehternet module.The software and hardware implementation of the PTP timer to 107 and 417 are the  same.Therefore, the control code is also the same.The controls are very simple.Unfortunately, I can see incorrect behavior PTP timer  STM32F417.Let us add one more problem.It surprised me.Now I see a significant slowdown account PTP timer. About four times.There has been no change in the program. This slowdown I see in the two microcontrollers. The remaining three microcontroller running the same program. They count rates are normal. Sounds like bullshit.Now plan to observe the behavior of timer at different frequencies.  However, while I am doing the only conclusion. Unfortunately, this HARDWARE DEFECTS  STM32F417 microcontroller revision B.At this  point, despite the statements, the microcontroller STM32F17 revision B NOT SUPPORT ptp protocol. I had high hopes for this microcontroller. For my project is a disaster.

[korrav]

Posted on March 06, 2013 at 16:48

I put part of their project. It includes implementation of a protocol for ptp STM32F4Timer counter can be observed in theregisters PTPTSHR and PTPTSLR. Target time - registers PTPTTHR and PTPTTLR.When the value of the timer reaches the PTP Target Timeinterrupt is generated.void ETH IRQHandler (void) - interrupt handler. It value Target Time is advanced by five seconds.If you comment out the line

while (ETH_GetMACITStatus (ETH_MAC_IT_TST) == SET);

then after a few iteration value Target Time stops updating.If you do not comment out the line in release mode, the program willforever stuck in an interrupt handler.For the device to become a master in the PTP protocol, set the Preprocessor Symbols ID_EMMITER =0, slave - ID_EMMITER = 1.By the way, despite the resolution, time stamps are not generated. This is evident from the transcript exchange ptp package I received in the program Wireshark. ________________ Attachments : ptp_timer.zip : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HzbT&d=%2Fa%2F0X0000000bPZ%2F1IlvR0mcyRdxuOnBNnNyBaVo5iSER3onbYwVY9G6nyw&asPdf=false

[hgiraldos]

Posted on July 18, 2013 at 09:06

Hi all,

I find myself doing my final degree project and I have the same problem. Although I have integrated the PTP module in FreeRTOS.The flag ETH_MACSR is not cleared when the register is read. I attach the interrupt fuctio I would appreciate any help.void ETH_IRQHandler(void){  portBASE_TYPE xHigherPriorityTaskWoken = pdFALSE;  #if LWIP_PTP //declaration  struct ptptime_t next_trigger;#endif    /* Frame received */  if ( ETH_GetDMAFlagStatus(ETH_DMA_FLAG_R) == SET)   {    /* Give the semaphore to wakeup LwIP task */    xSemaphoreGiveFromISR( s_xSemaphore, &xHigherPriorityTaskWoken );     }#if LWIP_PTP  if(ETH_GetMACITStatus(ETH_MAC_IT_TST) == SET) {        /* set next trigger time */    /* this should not be in the past, because it will trigger imidietly */    ETH_PTPTime_GetTime(&next_trigger);    /* Toggle LED */    STM_EVAL_LEDToggle(LED2);    next_trigger.tv_sec += 5;    ETH_SetPTPTargetTime(next_trigger.tv_sec, 0);    /* enable next trigger */    ETH_EnablePTPTimeStampInterruptTrigger();  } #endif  /* Clear the interrupt flags. */  /* Clear the Eth DMA Rx IT pending bits */  ETH_DMAClearITPendingBit(ETH_DMA_IT_R);  ETH_DMAClearITPendingBit(ETH_DMA_IT_NIS);      /* Switch tasks if necessary. */   if( xHigherPriorityTaskWoken != pdFALSE )  {    portEND_SWITCHING_ISR( xHigherPriorityTaskWoken );  }}

[sekat]

Posted on August 15, 2013 at 14:16

Add my information about this problem.

I have the STM32F407 (ID=0x413, Rev Z) on Evaluation Board (Discovery) + Embest (Ethernet)) The flag ETH_MACSR TSTS is not cleared and the CPU either goes into an infinite loop on WHILE, if it exist, or infinite loop on the ETH_IRQHandler, If not exist.Observed some strange effects with using debugger (ST LINK):1. If open Window View->SystemViewer->Ethernet_PTP, this flag resets. And infinit loop(if it was occure) is ended after some cycles. 2. The accuracy of the PTP algoritm down to ~ 3 .. 4 times when Debug Session is started.May be someone have ingformation from official support ST? May be its problem early revisions of chip? Enywhere exist bugfix report of chip revision?Can anybody help me?

[Tesla DeLorean]

Posted on August 15, 2013 at 15:50

Debuggers are invasive, they do not have a magic way of touching registers that doesn't clear/set other status bits indicating they have been touched. ie a debugger can't read USART1->DR without clearing USART1->SR RXNE

When debugging these types of peripherals you need to output telemetry from your own code about the internal states as you process them in the normal course of operation. ST maintains a list of

http://www.st.com/web/en/support/mcu_design_consultants.html

to provide project expertise and staffing. Have you reviewed the errata? If you have a clearly demonstrable fault you'd want to furnish that to a local ST rep or FAE, and seek support via that route. Or submit a ticket via the web interface.

[sekat]

Posted on August 16, 2013 at 07:19

From: clive1

Posted: Thursday, August 15, 2013 3:57 PM

Debuggers are invasive, they do not have a magic way of touching registers that doesn't clear/set other status bits indicating they have been touched. ie a debugger can't read USART1->DR without clearing USART1->SR RXNE

Hi clive1 !!!Thank you for quick answer. Need some more information about ''invasive'' og debuggers.Its clear, that reading some sensitive bits by debugger is equvivalent to reading of their from the inside by the user code.My question is... Does the debugger give the same invasive effect on the programm execution time? Can change results when use debugging for DSP code? It is clear that breakpoints do not use in this case.