Lnk_mis ?

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
Not applicable
Hi,

Has anyone experienced TwinCAT3 online state, flicking between reported OP and OP LNK_MIS A ?

We see this with our XMC43 based boards, but not with the Relax XMC43/48 boards, they show steady OP state

One difference, is that for the EtherCAT In+Out PHY, we use the Microchip KSZ8051MLLI. In contrast, the Relax boards use the Broadcom BCM5241XA1KMLG. We opted for the Microchip IC for reasons of materials commonality with our other product lines.

Our boards, and the Relax boards, both work, in terms of EtherCAT communications, and show similar performance. So this LNK_MIS A error would appear to be fairly benign. It would be nice though, to know why we see the difference, and to have all the boards work the same. Maybe, our boards are rightly reporting an error, and the Relax boards are inadvertently masking it !

Googling LNK_MIS took us to the Beckhoff site, but that didn't tell us much about the LNK_MIS state.

The flicking between OP and OP LNK_MIS A status, is observed to occur at about 1 Hz. It shows on the Online tab, for I/O > Devices > Device 1 (EtherCAT), and under that, Box 1 (XMC_ESC). All other reported status appears to be the same, for our boards and the Relax boards.

I found no entries for LNK_MIS in this forum, or anywhere else online, apart from the Beckhoff site.

Best regards,

David King
0 Likes
12 Replies
MichaelIFX
Employee
Employee
50 replies posted 25 replies posted 10 replies posted
Dear David,
I think a regular link miss every seconds breaks the complete ring for a while.
So this might not be a problem for your device in a lab environment but the entire ring in an industrial environment might not be in favour.

I reviewed the latest BECKHOFF phy selection guide on your device:
https://download.beckhoff.com/download/document/io/ethercat-development-products/an_phy_selection_gu...
2617.attach

The link-signal from the PHY is used by the ESC to open/close the ports.
So it might be better, to configure your phy to use LINK LED.
What is the setup you use at the moment?

In regard to the broadcom-phy used on our boards, I do not see why there should be a regular link miss and therefore why the broadcom-phy should mask it.
So let's first check the root-cause of the link-loss you see. And if it is "real" we should think about why the broadcom-phy masks it.

Michael
0 Likes
Not applicable
Hi Michael,

Thanks for that, understood. I might need to defer to the project hardware engineer on this. But to answer best I can, for our EtherCAT In & Out Microchip KSZ8051MLLI PHY, we have LED0 connected to XMC43 pins 1.15 & 15.3 (allocated to ECAT_SSC_0 APP resource p0_link & p1_link), and also via 330R dropper resistor to Wurth 7499010211A RJ45 Magjack yellow LED pin, respectively. LED1 for both is pulled up via 4K7 resistor to 3V3.

Thus, ostensively the same as XMC43 Relax Broadcom BCM5241XA1KMLG PHYs, albeit LED0&1 instead named LED1&2 (although I haven't checked the respective PHY datasheets that just a name difference, or for other details regarding these pins). Also the dropper 270R not 330R, and the LEDs being discrete.

We are connecting TwinCAT3 to our EtherCAT In port. The yellow and green LEDs are observed to pulse, nearly synchronised, at a seeming 5Hz approx, I can scope if need be. XMC43 Relax is as I recall the same, in this regard.

To mention, my initial post above, had an error: The online tab for 'Box 1 (XMC_ESC)', shows steady OP state, but under DLL Status, Port A flicks at about 1Hz, between 'Carrier / Open', and 'No Carrier / Closed'. Ports B-D are steady latter, with C&D greyed. Also at 1Hz rate, under 'Box 1 (XMC_ESC)', 'InputToggle' flicks between 0 and 1, and 'State' flicks 8 and 5128. I couldn't find any info on what those mean. But mentioning, in case relevant.

XMC43 Relax is as I recall the same, except Port A steady former, and different behaviour for 'InputToggle' and 'State'. I can run-up our XMC43 Relax board to confirm if need be.

Meantime, I'll give the PDF a read through. I was aware of that document, from the hardware engineer, but I've not seen before. About the KSZ8051 MLL/MNL comment 'Either enable MI Link Detection and Configuration or use LINK LED (requires enabling via management interface)', we're not, as far as I'm aware, doing either of those things..

Best regards,

David
0 Likes
Not applicable
Hi Michael,

Here's some added information, in case of use:

1) The Online tab, for I/O > Devices > Device 1 (EtherCAT), flicks at about 1Hz, between State 'OP' and CRC 0, and State 'OP LNK_MIS A' and CRC blank - I didn't mention CRC before.

2) With the ECAT_SSC_0 APP, we have APP outputs led_err and led_run driving a P1.10 red LED, and P1.11 green LED, they're off and on, respectively.

3) About the management interface, I've found that's an ECAT_SSC_0 APP setting, see green-circled, on first attachment. As shown, it's checked.We would have inherited this, from the DAVE example EtherCAT project. Likewise, the other settings.

Turning now to the Infineon XMC4300 Relax board, to see what differences I can see, either in configuration or behaviour:

The Online tab for I/O > Devices > Device 1 (EtherCAT), reports steady State 'OP' and CRC 0. 2) and 3), are identical.

On the online tab for Box 1 (XMC_ESC), under DLL Status, Port A shows steady 'Carrier / Open', State steady 8, EtherCAT In port yellow LED steady on, and green LED pulses much quicker. I would say, at 20Hz approx.

With the XMC4300 Relax board, the yellow LED is driven by the Broadcom BCM5241XA1KMLG PHY LED1 output, and connected also to XMC43 pin 1.15, as allocated to ECAT_SSC_0 APP input 'p0_link'. With the green LED being driven by APP output 'led_link_act_p0', connected to XMC43 pin 1.12.

Our board is identical to the last paragraph, except that Microchip KSZ8051MLLI PHY LED0 output used instead, due to mentioned LED0&1 instead of LED1&2 naming difference.

Looking at the KSZ8051MLLI PHY datasheet, second attachment extract, in default LED mode 00, as red-circled, the PHY LED0 output blinks if link activity, see blue-circled. So I would say that, is the origin, of the flicking behaviour we see.

Does our PHY need to operate instead in LED mode 01, as orange-circled ? This presumably, would make the PHY LED0 output steady while link activity, as is the case for the Relax board BCM5241XA1KMLG PHY corresponding LED1 output.

Is steady yellow LED the intent for active EtherCAT links ?

If so, would you know how we can change our PHY register bits 1f:5:4, from 00 to 01, to effect the change, from blinking to steady ?

Presumably, the XMC43 must do this via the PHY management interface. However, that is under control, of the ECAT_SSC_0 APP and Slave Stack Code (SSC) components. Unchecking the green-circled makes the latter holler on build.

About the PHY address 0, purple-circled, that is presumably correct, to allow the mentioned components, to communicate with PHYs at their broadcast address. I did also try other values, 1 and 2, but that made no difference to our flashing yellow behaviour. I also tried checking the pink-circled, but that likewise made no difference.

Best regards,

David


2631.attach

2632.attach
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi David,

To accesss the PHYs please use the XMClib functions XMC_ECAT_ReadPhy() and XMC_ECAT_WritePhy().

Regards,
Jesus
0 Likes
Not applicable
Hi Michael (or any others),

Attached, is an extract from the Beckhoff PHY Selection Guide Version 2.5 2016-10-19 'an_phy_selection_guidev2.5.pdf', as attached to your email, which I've annotated.

Orange we're doing, we have pin 28 RXC / B-CAST_OFF pulled-up via 4K7 to 3V3. About green, we have no pull-up resistor for pin 19 MDC. Blue seems not to be applicable to our issue, as SPEED (10Base-T / 100Base-TX), is pin 43 LED1 / SPEED, we have this pulled-up via 4K7 to 3V3. It's the purple and pink I'm particularly interested in.

What does the purple mean? I could find no references anywhere, in the Beckhoff documentation, as below, the SSC Tool, the Infineon DAVE ECAT_SSC APP information, the corresponding DAVE settings, the generated DAVE code, this forum, the other Infineon forums, or Google. But perhaps, I've not searched throughly enough.

About the pink, does the bracketed bit mean changing the LED mode from default 00 to 01, per my previous post. If so, how, anyone? I could find no references to a register write facility, in any of the mentioned places. I have any inkling that using the KSZ8051MLLI PHY shouldn't be this difficult, so I'm probably missing something, obvious, or have some knowledge gap, somewhere..

AN_EL9800.pdf / AN_ET9300.pdf / AN_FC11xx.pdf / EtherCAT Slave Design Quick Guide.pdf / an_phy_selection_guidev2.5.pdf


Best regards,

David2633.attach
0 Likes
Not applicable
Hi Jesus,

Our posts crossed. Ah ha, ECAT PHY read and write functions exist 🙂 I'll give them a try. I'm thinking, I'll need to read register 1Fh, set bit 4, and write back, and that should do the trick. I'll give it a go now.

Best regards,

David
0 Likes
Not applicable
Hi Jesus,

OK, I've tried as described. No luck, unfortunately.

I have added code as below, which reads ouMicrel KSX8051MLLI PHY Control 2 register (address 1Fh), sets bit 4, then writes Val back. Temporarily, to check that the code is working, before, I set Val to 1234, and after, I read the register back..

#define ECAT_PHY_ADDR 0 // ECAT PHY address
#define PHY_CONTROL_2 0x1F // PHY Control 2 register address
#define MODE_01 0b010000 // LED Mode 01

uint16_t Val = 1234; // EtherCAT PHY register

XMC_ECAT_ReadPhy( ECAT_PHY_ADDR, PHY_CONTROL_2, &Val ); // Reads as 0xFFFF or 0
XMC_ECAT_WritePhy( ECAT_PHY_ADDR, PHY_CONTROL_2, Val | MODE_01 ); // Writes 0xFFFF or 0x10
XMC_ECAT_ReadPhy( ECAT_PHY_ADDR, PHY_CONTROL_2, &Val ); // Reads as 0xFFFF or 0

If I place the code *after* the DAVE_Init() call, the first read changes the 1234 to 0xFFFF, so read is actively working. But the 0xFFFF value seems wrong, as KSZ8051MLLI datasheet pages 35 and 36, indicate the PHY Control 2 register default state, is 0 except for bits 8 and 15 set. If I single-step the XMC_ECAT_ReadPhy code, it seems to be working as intended, and indeed returns status XMC_ECAT_STATUS_OK, not XMC_ECAT_STATUS_ERROR.

The bit 4 set, of course, makes no change to the 0xFFFF value. The write similarly seems to work correctly, returning status XMC_ECAT_STATUS_OK.

And then the second read, likewise reads 0xFFFF. And seems to be working as intended, returning status XMC_ECAT_STATUS_OK.

I tried also reading the Basic Status register (address 1h), it likewise reads as 0xFFFF. It likewise seems wrong, as datasheet pages 28 and 29 show that register should have a mix of 0 and 1 bits.

I tried with ECAT_SCC APP setting 'PHY address of port 0' changed from default 0 to 1, in case for some reason, our PHY address is 1. But same results. I tried also changing to 2, same results.

I then tried placing the code *before* the DAVE_Init( ) call, results all the same, except the first read changes the 1234 to 0. Still seems wrong, given that the register default state, is as mentioned. The write with bit 4 writes 0x10 as intended. The second read, though, returns 0.

I am wondering, if the reads are yielding unexpected values, because we are using address PHY 0, being the broadcast address, so perhaps PHY's don't respond. Infact, perhaps this is essential, given that the XMC4800 Relax, XMC4300 Relax, and our XMC4300 board, all have *two* PHYs, one for EtherCAT In, and the other for EtherCAT Out, and that for all 3 boards, I see the MDC pin of the two PHYs are commoned, connecting to a single XMC pin. Ditto the MDIO pin. But if broadcast read doesn't work, I would have thought XMC_ECAT_ReadPhy would return XMC_ECAT_STATUS_ERROR..

Anyway, next, I tried changing the code, to perform just a write, of value 0x8110. This being, the datasheet page 35 and 36 default, of 0x8100 (ie bits 8 and 15 set), with the addition of bit 4 set. That didn't work, either, before or after the DAVE_Init() call.

I also tried 0x8120, just in case, when the datasheet says bits 5:4 must be value 01 for LED mode 01, it means bit 5 set and bit 4 clear. Same result.

I also tried 0x1081 and 0x2081, in case a byte-endian issue.

I tried also 0 and 0xFFFF, in case I could see any difference in behaviour, I imagine one of them, at least, would stop comms working entirely, if indeed writes are working..

So as matters stand, we remain with a blinking not steady EtherCAT PHY pin 42 LED0 output, and a consequent flashing yellow LED, and TwinCAT3 state flicking between OP and OP LNK_MIS A..

..unlike the Relax boards, which have a steady corresponding output from their Broadcom BCM5241XAKMLG PHYs, and consequent steady yellow LED, and steady OP state.

About my post before last, with the annotated extract, it would be good to know what the purple means, if you know, as perhaps that's another way..

Regards,

David
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi David,

I have checked on the XMC4300 relax kit and there I'm able to read the phy ids.

int main(void)
{
DAVE_STATUS_t status;

status = DAVE_Init(); /* Initialization of DAVE APPs */

if(status != DAVE_STATUS_SUCCESS)
{
/* Placeholder for error handler code. The while loop below can be replaced with an user error handler. */
XMC_DEBUG("DAVE APPs initialization failed\n");

while(1U)
{

}
}

uint16_t phyid1;
XMC_ECAT_ReadPhy(0, REG_PHYIDR1, &phyid1);
uint16_t phyid2;
XMC_ECAT_ReadPhy(0, REG_PHYIDR2, &phyid2);

/* Placeholder for user application code. The while loop below can be replaced with user application code. */
while(1U)
{

}
}


Can you check with the debugger the value of the registers MII_PDI_ACS_STATE and MII_ECAT_ACS_STATE in your case? Both should read 0 before trying to access the MII.

Regards,
Jesus
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi David,

You can find more info about the MI Link Detection and Configuration at https://download.beckhoff.com/download/document/io/ethercat-development-products/ethercat_esc_datash....

Regards,
Jesus
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi David,

I could also confirm the XMC_ECAT_WritePhy().
Could you show the schematics?

Regards,
Jesus
0 Likes
Not applicable
Hi Jesus,

Thanks as always to yourself and others at Infineon for the support. I try only to post issues that are proving tricky to resolve.

About the XMC 4300/4800 Relax kits, I did wonder, whether the Broadcom BCM5241XA1KMLG PHY had internal registers, so I could check whether register read/write worked on the kits. The 2-page BCM datasheet/product-brief, mentions MII Registers, but doesn't give details. Perhaps it's common knowledge that generally PHYs have the following, at least:

#define REG_PHYIDR1 2 // PHY Identifier 1
#define REG_PHYIDR2 3 // PHY Identifier 2

Within my running code, with my PHY Control 2 (PC2) register write to 0x8110, immediately after the DAVE_Init() call, I find the following two statuses are both 0 just before the PC2 write, and the first status becomes 1 immediately after the PC2 write, and remains so. This found by reading the values of the two statuses, just before the PC2 write, just after, and thereafter continuously, and placing the read statuses in an Modbus response message that's outgoing anyway.

ECAT0->MII_PDI_ACS_STATE
ECAT0->MII_ECAT_ACS_STATE

If I instead perform the PC2 write immediately before the DAVE_Init( ) call, the statuses are 0 throughout.

About the ECAT0->MII_PDI_ACS_STATE change from 0 to 1, this presumably, is courtesy the following function, within xmc_ecat.c. I did a search within files, and it's the only place that ECAT0->MII_PDI_ACS_STATE is written, by software. Indeed, I see the following function is called in two places only, at the start of XMC_ECAT_WritePhy() and XMC_ECAT_ReadPhy().

/* The function defines the access state to the MII management for the PDI interface*/
__STATIC_INLINE void XMC_ECAT_lRequestPhyAccessToMII(void)
{
ECAT0->MII_PDI_ACS_STATE |= 0x01;
}

Seems then that once ECAT0->MII_PDI_ACS_STATE is set to 1, it remains so. ECAT0->MII_ECAT_ACS_STATE looks never to be written, by software.

Many thanks, for the link to the document as below. I've not previously seen this or were aware of it.
Beckhoff Hardware Data Sheet Section I 'ethercat_esc_datasheet_sec1_technology_2i2.pdf'

I've read the sections that talk about 'MI Link Detection and Configuration', specifically 4.1 and 4.2, and 5.6 and 5.7. From what I can gather, the EtherCAT Slave Code (ESC) link status is determined from the following, in the preference order shown:

1) A PHY LED steady physical output signal, referred to as LINK_MII, in the preference order shown. But never from a toggling Link/Activity signal, as we have presently 😞

a) 100 Mbit/s Full Duplex link active
b) 100 Mbit/s link active
b) Link active

2) Reading PHY registers, via the MII Management Interface, aka MDC and MDIO. The document refers to this as 'MI Link Detection and Configuration'. From what I can see, this comprises the link is '100 Mbit/s Full Duplex Auto-Negotiation', and 'active', although the document doesn't say which registers it uses to determine 'active'. As yet, I've not trawled the XMC code to see if I can ascertain.

3) Counting receive errors, 32 and you're out. It refers to this as 'Enhanced Link Detection'. Section 5.7 refers.

From the above, seemingly one answer for us, if we cannot manage to read/write PHY registers, is instead of using our PHY toggling LED0 output for 1), we instead use the steady LED1 output, which indicates 1b), at least. Although it may just indicate '100 Mbit/s selected', whether active or not. We'd need to check.

Even so, it remains the case that if PHY register read/write is not working, that's a problem, on its own merits.

The document tells me that I can find out which of 1) 2) and 3) the ESC is using, can be determined by reading the below. So I've done that, at the same times as I was reading the two statuses. I find that both are 0 before and after the PC2 write, but subsequently become the values shown:

ECAT0->ESC_DL_CONTROL 32-bit steady 0000 0000 00000 0111 1111 1100 0000 0001
ECAT0->ESC_DL_STATUS 16-bit toggles rapidly between 0101 0110 0001 0111 and 0101 0101 0000 0111, ie bits 9 8 4 toggling between 1 0 1 and 0 1 0

Google tells me, via document 'https://download.beckhoff.com/download/document/io/ethercat-development-products/ethercat_esc_datasheet_sec2_registers_2i7.pdf' section 3.17,
that DL Control bits indicate:

0 EtherCAT frames are processed, Non-EtherCAT frames are destroyed
8:9 Port 0 auto
10:15 Ports 1-3 closed
16:18 Default RX FIFO size

And via section 3.19, DL Status bits indicate:

0 EEPROM loaded correctly, PDI operational (access to Process Data RAM)
1 PDI Watchdog reloaded
2 Enhanced Link detection activated for at least one port (ah, so 3) above is being used, well that's good news 🙂

4 Physical link on Port 0 toggling, between 0:No link, and 1:Link detected (that's bad news, and symptomatic of our toggling LED0 😞
5:7 No physical link on ports 1-3 (as expected)

8 Loop Port 0 toggling between 0:Open, and 1:Closed (ditto bit 4 comment)
9 Communication on Port 0 toggling between 0:No stable communication, and 1:Communication established (ditto bit 4 comment)

10:15 Loop Ports 1-3 all 1:Closed and 0:No stable communication (as expected)

Then, I tried reading out the below:

ECAT0->MII_CONT_STAT 16-bit steady 0000 0000 0000 0010
ECAT0->MII_PHY_ADR 8-bit steady 0000 0000 (as expected)
ECAT0->MII_PHY_REG_ADR 8-bit steady 0000 0000 (as expected)

Section 3.46 tells me that the MII Control bits indicate:

0 0:Write disabled, as opposed to 1:Write enabled (which is perhaps, why PHY register write is not working)
1 Management Interface 1:PDI control possible, as opposed to 0:Only ECAT control possible (not quite sure what this means)
2 MI link detection (link configuration, link detection, registers 0x0518-0x051B) 0:MI link detection not available, as opposed to 1:MI link detection active (ah, so 2) above is not being used, that's not good news, but doubtless due to bit 0 state)

7:3 PHY address of port 0, is 0 (as expected)
9:8 Command register 00:No command/MI idle (as expected)
12:10 Reserved
13 0:No read error
14 0:Last Command was successful (really? that's not what I'm experiencing..)
15 0:MI control state machine is idle (you're telling me!)

So, I then tried adding the following, before my PHY register read and write code.

ECAT0->MII_CONT_STAT |= ECAT_MII_CONT_STAT_W_EN_Msk; // (latter is 1)

But it made no change to anything 😞
Indeed, the set of bit 0, is blocked, I'm not sure how that occurs, I even tried eg the following:

ECAT0->MII_CONT_STAT = 1;

I even tried instead within the XMC_ECAT_WritePhy() and XMC_ECAT_ReadPhy() functions,
eg see /* write enable */ commented addition below, but the same. This is very odd,
as the functions also write to MII_CONT_STAT, see /* write instruction */ below.

XMC_ECAT_STATUS_t XMC_ECAT_WritePhy(uint8_t phy_addr, uint8_t reg_addr, uint16_t data)
{
XMC_ECAT_STATUS_t status;

XMC_ECAT_lRequestPhyAccessToMII();
ECAT0->MII_CONT_STAT |= 0x0001U; /* write enable */

ECAT0->MII_PHY_ADR = phy_addr;
ECAT0->MII_PHY_REG_ADR = reg_addr;
ECAT0->MII_PHY_DATA = data;

ECAT0->MII_CONT_STAT |= 0x0200U; /* write instruction */
while ((ECAT0->MII_CONT_STAT & ECAT_MII_CONT_STAT_BUSY_Msk) != 0U){}
:

I would try disassembly single-step debugging, to understand why the bit 0 set, is not taking.
But I find the DAVE4 Disassembly window sometimes displays code, and is sometimes empty, and it's the latter, just now.
Googling the issue and looking on the forum yielded no answers to that. Any ideas?

Best regards,

David
0 Likes
Not applicable
If you've been entertained by this thread, you might be pleased to hear, that our Micrel KSZ8051MLLI EtherCAT PHYs, have now decided to burst into life at address 1, a trick they were unwilling to pull Friday. Separately, I've communicated the good news to Jesus.

This morning, I tried again with XMC_ECAT_ReadPhy() function calls, including one each for all possible addresses, 0 to 7. And bingo, read worked at address 1 ! 🙂
No idea why this didn’t work Friday, when I was trying read at address 0, 1 and 2..

Anyway, I’m now up and running, with EtherCAT PHY read and write: If I read the 'PHY Control 2' register, address 0x1F, I get 33024 decimal, so 1000 0001 0000 0000 binary. This being, the PHY datasheet default value. Good start! And if I OR in bit 4, and write back, LED mode successfully changes from default mode 00 (LED0 Link/Activity), to mode 01 (LED0 Link only), confirmed by a read-back. And bingo, our EtherCAT In and Out port yellow LED, is now glowing steady active, rather than flashing. And in TwinCAT3, state is now steady OP, rather than flicking between OP and OP LNK_MIS A. In other words, per the Relax boards. Bingo ! 🙂

But perhaps instead, we should be keeping with LED mode 00, and for each EtherCAT PHY, our board should instead have the LED1 output (Speed in mode 00), connected to our corresponding XMC LINK_MII input. Certainly, the Beckhoff ‘Hardware Data Sheet Section I Version 2.2 Date 2014-07-07' document would suggest that is preferable. The Relax boards though, use the Broadcom BCM5241XA1KMLG PHY LED1 output, which is seemingly on for link activity, otherwise off. So we could just stay in good company 🙂

In some ways, I am surprised that XMC_ECAT_ReadPhy() works at all, given that EtherCAT In and Out PHY, are both address 1, and have a common MII interface, ie MDCLK and MDIO lines. Both PHYs pipe-up if we do a register read. And if for whatever reason, register bit state differs between, they will try driving the MDIO line to opposing states. Seems a bit of a shortcoming in MII, if there are two or more PHYs connected to the same MDCLK and MDIO lines. It works for 'PHY Control 2' register because they have the same value, and any slight difference in when they assert bits onto the MDIO line, is not while the XMC 'is looking'. Writes of course, no problem, and indeed our write of 0x8110 to address 0x1F, goes successfully to both PHYs. Maybe I should just write 0x8110 without reading..

About my previous post, seems the XMC4300 (and XMC4800) omit the MII Management Interface status registers for the 4 PHY ports, register addresses 0x518-0x51B. And due to this, the ESC omits 2) 'MI Link Detection and Configuration'. Which is why the generated ESC or DAVE ECAT_SSC APP code lack XMC_ECAT_ReadPhy() calls. Indeed, per the post, ESC ECAT0->MII_CONT_STAT bit 2 is off, meaning ‘MI link detection not available’. And the code doesn’t set that bit, and makes no use of ECAT_MII_CONT_STAT_MI_LD_Pos/Msk. And thus why I can see no option to enable ‘MI link detection’, in the ‘ET9300 (EtherCAT Slave Stack Code) Tool’, or the DAVE ECAT_SSC APP settings..