ETH->MACISR TSIS unstoppable?

[HenrikGlader]

Hello there,

I'm playing with the NUCLEO-H743ZI2 board and having difficultis with PTP.

When TSIE (MACIER is set the interrupt is getting retriggered endlessly.

I've tried to clear TSIS by reading both MACISR as well as MACTSSR (TXTSSIS bit set).

The manual states this is a way to achieve this, but neither register is cleared.

BTW, the alternate way (MACCSRSWCR) semes not being supported altho I've tried that as well.

Just at the interrupt entry:

macisr = ETH->MACISR; // 0x1000

mactssr = ETH->MACTSSR; // 0x8000

macisr2 = ETH->MACISR; // 0x1000

mactssr2 = ETH->MACTSSR; // 0x8000

macisr3 = ETH->MACISR; // 0x1000

 

Where am I doing the wrong thing?

Thank you for any input.

The ST Community moderator has edited the post to comply with the code sharing guidelines. In the future, use the </> button to paste code and linker script content. For more information, see: How to insert source code.

[HenrikGlader]

The snipplet full:

volatile unsigned macisr;

volatile unsigned macisr2;

volatile unsigned macisr3;

volatile unsigned mactssr;

volatile unsigned mactssr2;

void ETH_IRQHandler(void) __attribute__ ((optimize("O2")));

void ETH_IRQHandler(void)

{

GPIOA->BSRR = 1<<0;

macisr = ETH->MACISR;

mactssr = ETH->MACTSSR;

macisr2 = ETH->MACISR;

mactssr2 = ETH->MACTSSR;

macisr3 = ETH->MACISR;

HAL_ETH_IRQHandler(&EthHandle);

GPIOA->BSRR = 1<<16;

return;

}

 

[HenrikGlader]

Ah, forget it...

You must read the seconds capture as well.

I would call that waste.

[LCE]

Shouldn't be too much of a waste at probably >= 400 MHz.

I always read the seconds, just to check if these are off.

Curious: are you using this for target time or the PTP offload feature?

[HenrikGlader]

Assuming reading peripherals is tad slower one would avoid superfluous reads and writes?

I went down the offload path which I find nice doing sync at 128Hz.

Time is of no concern but syncronisation.

[LCE]

Interesting!

How good is the sync with PTP offload at high ethernet traffic (>20M) ?

I tried PTP offload on a H733, it worked quite well, but as soon as traffic went up, sync was not good enough anymore.

I need reliable < 0.5 µs, which I can achieve with a heavily modified PTPd, but astonishingly not with the offload.
Which makes me think there's a hardware bug, but hard to say because the offload documentation is the worst I've seen until now.

[HenrikGlader]

Well, our goal is a local domain with a central switch (master) and a few participating devices.

In this way we hope to limit the packets substantially.

For now I have an ordinary switch in between which limits the synchronicity to about ±70ns (another switch at ±200ns). No switch (1m cable) is about ±15ns.

Yes, the documentation is not at its best, but that's what it is.

[LCE]

Thanks for the info!

We will have the same setup, PC -> switch -> several devices which need to be in sync to each other.

And have you tested sync with some ethernet traffic ?

We got it below 100 ns with PTP offload - until we turned on data streaming...

[HenrikGlader]

De nada : )

Actually, we only have RT devices connected.

During tests I use a PC (wireshark debug) but the PC sometimes disrupts the sync.

We have far more control on our devices, which are quite silent but that may change in the future.

Basically I'm leaning on the switch ability to sort priorities.

[LCE]

We use TCP for real-time measurement data streaming.
But as soon as we start that, PTP offload gets so bad that the devices get out of sync.
Even with the same sync rate, algorithms, and lucky packet filtering as with the PTPd stuff.

So with the documentation we have, I could only guess that we either have a bug in the offload stuff, or there's some hardware problem (like PTP offload does the timestamping not exactly before giving the packet to the PHY).

The switch... I'm working with a PTP-capable switch, and got the best results by turning all its PTP features off.

And we definitely turn any PTP stuff on the PC side off.

[HenrikGlader]

I'd guess turning off PTP in the switch would yield that.

To ensure priorities you might have to do traffic shaping as well, that's our plan.

[LCE]

At least on the STM32 side, traffic shaping will be almost impossible with PTP offload.

Not enough info about this feature running completely in the background. My tests showed me that the offload packets cannot be given / have no priority.

This is possible with the "manual" PTPd stuff and its timers via UDP.

[HenrikGlader]

I might be wrong but don't see traffic shaping making any sense at end points.

In our case the switch will handle the profile.