i.MX28 MAC1 IEEE1588 in slave mode and interrupt

Showing results for 
Search instead for 
Did you mean: 

i.MX28 MAC1 IEEE1588 in slave mode and interrupt

Contributor III


mac0 and its IEEE1588 block is configured and it works.

mac1 IEEE1588 is configured to slave mode.

I clear interrupt pendings for IEEE1588 slave (CCB_INT), enable proper interrupt mask (CCB_INT_MASK), set mac1 match compare value (COMP_REG).

The interrupt flag is set as expected but interrupt is not generated.

Does IEEE1588 in slave mode generate mac1 or mac0 interrupt?

I tried to catch the interrupt from both mac0 and mac1.

However mac1 interrupt is never generated and mac0 interrupt is generated only by mac0 packets (PTP packets are stamped properly).

mac1 is not used for packets - only mac1's IEEE1588 block is used so ECR register is only used for initial configuration.

I reset mac1, wait 10us, clear mac1 pending interrupts (IEVENT), set ENA_1588 bit and then reset IEEE1588, set counter to 0, set ATIME_INC the same as for master and finally set the clock as slave.

Should I also set ETHER_EN bit despite MAC is unused for packets indeed?

Is it possible to reset mac without resetting of IEEE1588 counter?

Otherwise each cable replugging destroys synchronized clock.

Is it necessary to reset mac on cable replugging?

best regards

Labels (1)
0 Kudos
3 Replies

Contributor III

Can you give more detailed documentation or example how to use compare/capture at IEEE1588 block with interrupts?

MCIMX28 Reference manual contains only the ICOLL table 5-1:

source numberinterruptdescription
101enet_mac0_irqMAC0 IRQ
102enet_mac1_irqMAC1 IRQ
103enet_mac0_1588_irq1588 of MAC0 IRQ
104enet_mac1_1588_irq1588 of MAC1 IRQ

MAC0 configured as MAC, enabled for IEEE1588 timestamping - works

MAC1 unused as MAC, IEEE1588 in slave mode - irq 102, 104 never generated, 102 and 103 are generated but it seems they are not related to match event, Moreover 103 is generated more often likely when SD card is read!

I have found the thread without any comment:

IEEE 1588 Timer

Has somebody ever tested the match compare feature and slave mode?

Unfortunately the MX53 patch is not useful for MX28 IEEE1588 events: Stamp-Kernel-Extentions/0324-ENGR00131580-2-PTP-Support-IEEE-1588-interface-func.patch at master · l...

Are the Vybrid's issues common with MX28?

Re: IEEE1588 time-stamping issue

According to MX28 FSL BSP (linux- CAPTURE bit is written to ATIME_CTRL twice before ATIME readout. But the second readout in fec_get_curr_cnt() is done without any delay.

In the patch https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/net/ethernet/fre...

additional delay for i.mx6 has been added. Does MX28 require the delay for 40MHz PTP clock?

BTW. Re: MII interface recommended for IEEE 1588 on Vybrid if best jitter performance required

It looks MAC reset can be not used on fec_resert() like for mac1 reset issue (imx28-enet-patch.tgz):

iMX28 Ethernet controller issue

FEC driver about dual LAN port

Naoum Gitnik suggestion:

(I do not have permission to access this link and cannot even read your questions; the possible reason for that is that I am not supporting the i.MX28 device.)

My specialty is the Vybrid family, and we indeed had some IEEE1588 issues (or rather specifics) possibly applicable to other processors using the same IEEE1588 block.

You may check the 'Vybrid Processors' Community for this information.

0 Kudos

NXP Employee
NXP Employee

Hi JohnU,

You could try with the “i.MX28 SDK 2010.08 IEEE1588 stack for Linux”, available here.

Additionally, on the following thread is included a patch which solves the issues when using both ETH interfaces:


Hope this will be useful for you.
Best regards!

Note: If this post answers your question, please click the Correct Answer button. Thank you!

0 Kudos

Contributor III

Thank you Carlos.

The IEEE1588 stack uses 2.6.35 which does not support event lines.

The second link, I found before too, is helpful against reset issue.

Unfortunately there is no information about:

- IEEE1588 slave mode

- IEEE1588 interrupt

- IEEE1588 event lines.

0 Kudos