root@POWERLink_ZYBO_v2_default:/# ./demo_cn_console
----------------------------------------------------
openPOWERLINK consolPLK: + powerlinkOpen...
e CN DEMO application
using openPOWERLINK Stack: V2.3.0
------PLK: + powerlinkOpen - OK
----------------------------------------------
1970/01/01-04:31:1Initialize kernel modules...
7 INFO GENERIC demo_cn_console: Stack Version:V2.3.0 hrestimer_init: IoAddr=608fe000
Stack Configuration:0x00000002
Initializing openPOWERLINK stackhrestimer_init: interrupt0 registered (return=0)
...
1970/01/01-04:31:17 INFO CONTROL Initializing ophrestimer_init: interrupt1 registered (return=0)
enPOWERLINK stack
Initialize ctrl module ...
Checking for kern(edrv_init) Registering the driver to the kernel...el stack...
Kernel features: 0x00000002
Kernel version: 0x0203(initOnePlatformDev) IOMEM Resource initialization...0000
Initialize OBD module...
Done alizing kernel modules ...
(initOnePlatformDev) IRQ Resource initialization...Done
MEM_RESOURCE: Start 0x(E000B000), End 0x(E000BFFF)
Requesting IRQ resource ...Done
Allocation of Tx Buffers ...Done
Allocation of Tx Desc ...Done
Allocation of Rx Desc ...Done
Allocation of Rx Buffers ...Done
initOnePlatformDev finished with 0
Done
Local MAC = 0x00 0x04 0xa3 0xd2 0x20 0x6f
Initialize Eventu module...
Initialize Timeru module...
initialize error handler nmtk_process(NMT-event = 0x0010): New NMT-State = 0x019
user module...
Initialize DlluCal module...
Initialize Pdou modunmtk_process(NMT-event = 0x0020): New NMT-State = 0x029
le...
Initialize Timesync module...
Initialize NMT_CN module...nmtk_process(NMT-event = 0x0021): New NMT-State = 0x039
Initialize NMTu module...
Initialize SdoCom module...
Initialinmtk_process(NMT-event = 0x0023): New NMT-State = 0x079
zing process image...
Size of process image: Input = 1 Output = 1
19pdokcal_allocateMem() Allocated memory for PDO at 5e54d000 size:2068/0
70/01/01-04:31:18 INFO GENERIC Allocating process imapdokcal_initPdoMem() PdoMem:5e54d000 size:2068 Triple buffers at: 5e54d814/5e54d814/5e54d814
ge: Input:1 Output:1
oplk_allocProcessImage(): Alloc(1, 1)
oplk_allocProcessImage: Alloc(0x39070, 1, 0x391d8, 1)
Linking process image vars:
Linking process vars... ok
start POWERLINK Stack... ok
Digital I/O interface with openPOWERLINK is ready!
-------------------------------
Press Esc to leave the programm
Press r to reset the node
Press i to increase digital input
Press d to decrease digital input
Press p to print digital outputs
-------------------------------
Synchronous data thread is starting...
1970/01/01-04:31:18 EVENT STATE_CHANGE NmtGsOff->NmtGsInitializing Originating event:NmtEventSwReset
Stack entered state: NmtGsInitializing
nmtu_processEvent(): NMT state machine announce change of NMT State
1970/01/01-04:31:18 EVENT STATE_CHANGE NmtGsInitializing->NmtGsResetApplication Originating event:NmtEventEnterResetApp
Stack entered state: NmtGsResetApplication
nmtu_processEvent(): NMT state machine announce change of NMT State
1970/01/01-04:31:18 EVENT STATE_CHANGE NmtGsResetApplication->NmtGsResetCommunication Originating event:NmtEventEnterResetCom
Stack entered state: NmtGsResetCommunication
nmtu_processEvent(): NMT state machine announce change of NMT State
setupTxPdoChannelTables() TX channel count: 1
checkAndConfigurePdo() mappParamIndex:1600 mappObjectCount:0
checkAndConfigurePdo() mappParamIndex:1601 mappObjectCount:0
checkAndConfigurePdo() mappParamIndex:1602 mappObjectCount:0
checkAndConfigurePdo() mappParamIndex:1a00 mappObjectCount:0
powerlinkMmap() vma: vm_start:36F7B000 vm_end:36F7C000 vm_pgoff:0
powerlinkVmaOpen() vma: vm_start:36F7B000 vm_end:36F7C000 vm_pgoff:0
pdoucal_initPdoMem() Mapped shared memory for PDO mem region at 0xnmtk_process(NMT-event = 0x0024): New NMT-State = 0x11C
36f7b000 size 2068
pdoucal_initPdoMem() Triple buffers at: 0x36f7b814/0x36f7b814/0x36f7b814
1970/01/01-04:31:18 EVENT STATE_CHANGE NmtGsResetCommunication->NmtGsResetConfiguration Originating event:NmtEventEnterResetConfig
Stack entered state: NmtGsResetConfiguration
nmtu_processEvent(): NMT state machine announce change of NMT State
1970/01/01-04:31:18 EVENT STATE_CHANGE NmtGsResetConfiguration->NmtCsNotActive Originating event:NmtEventEnterCsNotActive
Stack entered state: NmtCsNotActive
nmtu_processEvent(): NMT state machine announce change of NMT State
nmtk_process(NMT-event = 0x0026): New NMT-State = 0x11E
1970/01/01-04:31:23 EVENT STATE_CHANGE NmtCsNotActive->NmtCsBasicEthernet Originating event:NmtEventTimerBasicEthernet
Stack entered state: NmtCsBasicEthernet
nmtu_processEvent(): NMT state machine announce change of NMT State
This seems to be bad, the network device is silent which has been proven by wireshark.
What would be the correct workflow for using the emacps kernel module?
Regards,
Heiner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
is there an MN connected to the network respectively to your Zynq which is running the CN demo? Usually a CN enters "Basic Ethernet Mode" after some time if no POWERLINK frame from an MN was received (e.g. SoA or SoC).
Best regards,
Joerg
Last edit: Joerg Zelenka 2016-01-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello Joerg,
we have the same output from the cn as above, the mn did not recognize any cn. Can we use the powerlink emacps Kernelmodule if we the RTL8211E connected to the emacps driver over mdio?
my MDIO PHY address is 00001b (zybo_reference_manual). I also checked this in the schematics and in the original device tree from the vendor.
The other PHY specific register configurations seem to be correct, I reviewed this with the datasheet.
I've changed the MARVELL_PHY_ADDR = 0x01 in edrv-emacps.c and tested the fresh module on the board.
There are two new things:
1: the PHY Link & ACT LED are off after I run demo_(mn/cn)_console ( very bad )
2: when I start the MN (module / demo) i got
970/01/01-00:00:43 EVENT STATE_CHANGE NmtMsNotActive->NmtMsPreOperational1 Originating event:NmtEventTimerMsPreOp1
Stack entered state: NmtMsPreOperational1
nmtu_processEvent(): NMT state machine announce change of NMT State
veth_xmit: frame passed to DLL
veth_xmit: frame passed to DLL
veth_xmit: frame passed to DLL
veth_xmit: frame passed to DLL
veth_xmit: frame passed to DLL
Seems to be a problem with the Realtek chip?
Thanks and regards,
Heiner
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't have the Zybo or any other board with exactly that Realtek chip with me.
In order to debug your Realtek chip configuration you can use mdioPhyRead() to read out the phy registers and compare the settings with the data sheet.
Or as a workaround you can skip the mdioPhyWrite() calls in edrv-emacps.c temporarily, then the phy stays in its powerup configuration. In order to force the phy to enter 100 Mbps half-duplex connect it to a hub.
We are looking forward to a more generic solution which supports the Zybo board as well - currently the edrv is implemented for ZC702 devboard. So we are very thankful for your observations!
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
since Heiner and I are working together, I've also fiddled with this problem. Today I took the approach, that you also recommended by reading the PHY register. I decided to write to the PHY register the configuration to operate at 100Mbps in Full Duplex without Auto-Negotiation (since this overrides the 100Mbps at some point and I wanted to try it with the guarantee to have 100Mbps enabled). I still don't get anything returned to the network by the board, but it does seem to respond to the frames beeing broadcasted by the MN:
PLK:powerlinkInit()Driverbuild:Jan292016/16:20:16PLK:powerlinkInit()Stackversion:V2.3.0Allocatedmajornumber:246root@CONTROLLED_NODE:~#CN-Demo_K----------------------------------------------------openPOWERLINKconsPLK:+powerlinkOpen...oleCNDEMOapplicationusingopenPOWERLINKStack:V2.3.0----PLK:+powerlinkOpen-OK------------------------------------------------1970/01/01-00:Initializekernelmodules...00:21INFOGENERICdemo_cn_console:StackVersion:V2.hrestimer_init:IoAddr=6087e0003.0StackConfiguration:0x00000002InitializingopenPOWERLINKshrestimer_init:interrupt0registered(return=0)tack...1970/01/01-00:00:21INFOCONTROLInitializinhrestimer_init:interrupt1registered(return=0)gopenPOWERLINKstackKernelfeatures:0x00000002Kernelversi(edrv_init)Registeringthedrivertothekernel...on:0x02030000(initOnePlatformDev)IOMEMResourceinitialization...Done(initOnePlatformDev)IRQResourceinitialization...DoneMEM_RESOURCE:Start0x(E000B000),End0x(E000BFFF)RequestingIRQresource...DoneAllocationofTxBuffers...DoneAllocationofTxDesc...DoneAllocationofRxDesc...DoneAllocationofRxBuffers...DoneCurrentValueofreg:0x0018CurrentValueofthePHYCTRLRegister:0x1140CurrentValueofthePHYCTRLRegister(afterinit):0xa000CurrentValueofthePHYCTRLRegister(beforeendofinit):0x2100CurrentValueofthePHYStatusRegister(beforeendofinit):0x7949CurrentValueofthePHYSpecificCTRLRegister(beforeendofinit):0x016eCurrentValueofthePHYSpecificStatusRegister(beforeendofinit):0x6800initOnePlatformDevfinishedwith0Doneplatform41e30000.axi_quad_spi:Driverxilinx_spirequestsprobedeferralplatform41e00000.axi_quad_spi:Driverxilinx_spirequestsprobedeferralplatform41e20000.axi_quad_spi:Driverxilinx_spirequestsprobedeferralplatform41e10000.axi_quad_spi:Driverxilinx_spirequestsprobedeferralLocalMAC=0x000x1e0xc00xdd0x7e0x99Initializingprocessimage...Sizeofprocessimage:Input=1Outpnmtk_process(NMT-event=0x0010):NewNMT-State=0x019ut=11970/01/01-00:00:22INFOGENERICAllocatingprnmtk_process(NMT-event=0x0020):NewNMT-State=0x029ocessimage:Input:1Output:1oplk_allocProcessImage():Alloc(1,nmtk_process(NMT-event=0x0021):NewNMT-State=0x0391)oplk_allocProcessImage:Alloc(0x3b070,1,0x3b1d8,1)Linkingnmtk_process(NMT-event=0x0023):NewNMT-State=0x079processimagevars:Linkingprocessvars...okstartPOWERLIpdokcal_allocateMem()AllocatedmemoryforPDOat5e4ec000size:2068/0NKStack...okDigitalI/O interface with openPOWERLINK is readpdokcal_initPdoMem() PdoMem:5e4ec000 size:2068 Triple buffers at: 5e4ec814/5e4ec814/5e4ec814y!-------------------------------PressEsctoleavetheprogrammPressrtoresetthenodePressitoincreasedigitalinputPressdtodecreasedigitalinputPressptoprintdigitaloutputs-------------------------------1970/01/01-00:00:22EVENTSTATE_CHANGENmtGsOff->NmtGsInitializingOriginatingevent:NmtEventSwResetStackenteredstate:NmtGsInitializing1970/01/01-00:00:22EVENTSTATE_CHANGENmtGsInitializing->NmtGsResetApplicationOriginatingevent:NmtEventEnterResetAppStackenteredstate:NmtGsResetApplication1970/01/01-00:00:22EVENTSTATE_CHANGENmtGsResetApplication->NmtGsResetCommunicationOriginatingevent:NmtEventEnterResetComStackenteredstate:NmtGsResetCommunicationpowerlinkMmap()vma:vm_start:36FAC000vm_end:36FAD000vm_pgoff:0powerlinkVmaOpen()vma:vm_start:36FAC000vm_end:36FAD000vm_pgoff:01970/01/01-00:00:22EVENTSTATE_CHANGENmtGsResetCommunicatinmtk_process(NMT-event=0x0024):NewNMT-State=0x11Con->NmtGsResetConfigurationOriginatingevent:NmtEventEnterResetConfigStackenteredstate:NmtGsResetConfiguration1970/01/01-00:00:22EVENTSTATE_CHANGENmtGsResetConfiguration->NmtCsNotActiveOriginatingevent:NmtEventEnterCsNotActiveStackenteredstate:NmtCsNotActivenmtk_process(NMT-event=0x0026):NewNMT-State=0x11E1970/01/01-00:00:27EVENTSTATE_CHANGENmtCsNotActive->NmtCsBasicEthernetOriginatingevent:NmtEventTimerBasicEthernetStackenteredstate:NmtCsBasicEthernetrandom:nonblockingpoolisinitializednmtk_process(NMT-event=0x000A):NewNMT-State=0x11D1970/01/01-00:13:11EVENTSTATE_CHANGENmtCsBasicEthernet->NmtCsPreOperational1Originatingevent:NmtEventDllCeSoaStackenteredstate:NmtCsPreOperational1nmtk_process(NMT-event=0x0011):NewNMT-State=0x0291970/01/01-00:13:11EVENTSTATE_CHANGENmtCsPreOperational1-nmtk_process(NMT-event=0x0021):NewNMT-State=0x039>NmtGsResetApplicationOriginatingevent:NmtEventResetNodeStackenmtk_process(NMT-event=0x0023):NewNMT-State=0x079nteredstate:NmtGsResetApplication1970/01/01-00:13:11 EVENT pdokcal_allocateMem() Allocated memory for PDO at 5e4ec000 size:2068/0STATE_CHANGENmtGsResetApplication->NmtGsResetCommunicationpdokcal_initPdoMem()PdoMem:5e4ec000size:2068Triplebuffersat:5e4ec814/5e4ec814/5e4ec814Originatingevent:NmtEventEnterResetComStackenteredstate:NmtGsResetCommunicationpowerlinkVmaClose()vma:vm_start:36FAC000vm_end:36FAD000vm_pgoff:0powerlinkMmap()vma:vm_start:36FAC000vm_end:36FAD000vm_pgoff:0powerlinkVmaOpen()vma:vm_start:36FAC000vm_end:36FAD000vm_pgoff:01970/01/01-00:13:12EVENTSTATE_CHANGENmtGsResetCommunicatinmtk_process(NMT-event=0x0024):NewNMT-State=0x11Con->NmtGsResetConfigurationOriginatingevent:NmtEventEnterResetCnmtk_process(NMT-event=0x0007):NewNMT-State=0x11DonfigStackenteredstate:NmtGsResetConfiguration1970/01/01-0nmtk_process(NMT-event=0x0007):NewNMT-State=0x15D0:13:12EVENTSTATE_CHANGENmtGsResetConfiguration->NmtCsNotpdoklut_getChannel()channel:255index:0nodeId:0ActiveOriginatingevent:NmtEventEnterCsNotActiveStackenteredpdoklut_getChannel()channel:255index:0nodeId:0state:NmtCsNotActive1970/01/01-00:13:12EVENTSTATE_CHANGpdoklut_getChannel()channel:255index:0nodeId:0ENmtCsNotActive->NmtCsPreOperational1Originatingevent:NmtEvpdoklut_getChannel()channel:255index:0nodeId:0entDllCeSocStackenteredstate:NmtCsPreOperational11970/01/pdoklut_getChannel()channel:255index:0nodeId:001-00:13:12EVENTSTATE_CHANGENmtCsPreOperational1->NmtCsPpdoklut_getChannel()channel:255index:0nodeId:0reOperational2Originatingevent:NmtEventDllCeSocStackenteredpdoklut_getChannel()channel:255index:0nodeId:0state:NmtCsPreOperational2pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0pdoklut_getChannel()channel:255index:0nodeId:0.......andsoon
After the initialization is done, all the program does is continuously posting the pdoklut_getChannel() message. I would suspect, that this is a kind of response to the SoC frame being sent by the MN, since this behaviour is only observed, after a MN has gone active. From what I understand this should not be repeated continuously, since the state says something about PreOperational and should probably only entered for a short while before becoming operational. Could there be a clock timing problem or similar? If not, could you hint me at something, where I should look in particular going onward?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recommend to set the phys to 100 Mbps half-duplex (generally it could work with full-duplex, but just to be sure). Don't forget to conduct a software reset (msb in control reg) of the phy after you changed the speed, duplex mode and auto-negotiation bits! Also make sure that you do not enable isolate mode or loop back :)
From the log you shared it is very likely that the MN's frames are received correctly, because a CN enters the PreOperational states if a POWERLINK frame is received - PreOperational 2 is entered if the MN sends SoC frames (CN has received SoC: NmtEventDllCeSoc). Your CN does this correctly!
The pdoklut_getChannel() calls indicate that your CN handles PDOs, either because it receives PReq frames from the MN, or it prepares the PRes frame for transmission, or both. So it's valid behavior that pdoklut_getChannel() pops up continuously!
I would suggest that you connect the MN and CN to a hub (this forces 100 Mbps half-duplex). In addition connect a PC with a network interface card (disable TCP/IP for this NIC) and use it to trace the POWERLINK network with Wireshark. If needed, you can share the trace with us.
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have set the PHY's registers according to your recommendations. I'm not sure about the necessity to reset the PHY because on the one hand it does not work, i.e. if I set the reset bit, it does not clear itself and the application goes into BasicEthernet mode after a short while and on the other hand, the register documentation of the PHY states that all registers of the CTRL register would be reset to default values, which also doesn't work, as I have tried this (skipping the mdioPhyWrites) as well and the application goes into BasicEthernet here too.
Anyway, if I set the CTRL register to operate at 100 Mbps and Half-Duplex manually, the same behaviour as before is observed. The only thing I can see in the Wireshark is an SoC frame alternating with an SoA frame. In the SoA frame there is additional Info given in certain intervals (In the info, it states: tgt = 1 (or one of the other numbers 32, 110, 253 - which I think come from the predefined .cdc file) and IdentRequest).
This all ocurred with the Zybo being the CN and the PC being the MN, both connected to a switch, which is not connected to any other network. If I try to run the Zybo as MN, the same behaviour Heiner posted before ("veth_xmit: frame passed to DLL") occurs.
Do you have any further ideas? At the moment I cannot shake the feeling that either I am making some very stupid mistakes, or that the application/hardware just has fun to mess with me.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
due to the lack of a hub, I tried this with a direct connection with a crossover adpater in between, but the result is still the same. Can you recommend any other way to fix this?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
what speed and duplex mode is negotiated if you connect the Zybo directly with the PC (= MN)? Have you checked with Wireshark if there is any frame from the Zybo (IdentResp, PResp, ...)?
Maybe you can obtain a network card for the PC which allows setting the link speed and duplex mode to 100 Mbps half-duplex?
Of course the last possibility is to debug the phy registers with referencing to the datasheet...
Best regards,
Joerg
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
thanks for the hint, as I am not 100% certain about which settings the network interface used. In my mind I was still thinking about the hub, which would have provided the required settings (Hopefully) by default. I'm not in the office today, but I will check on this as soon as I get back on monday. I think adpating the correct network settings on the Linux workstation (MN) with ethtools or similar should do the trick.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had a quick look at the ZYBO reference manual and I don't see any special initialization settings for the RealTek Phy required.
Have you already checked the driver without configuring the PHY i.e. skipping the mdioPhyWrite() in the initOnePlatformDev() routine as suggested by Joerg?
The management interface to PHY do require a clock for which configuration is controlled by the MDIO interface clock (MDC) in the network configuration register EDRV_NET_CONFIG_REG. In the current implementation the driver configures the MDC to operate for 100Mb/s. I am not sure if it is possible to control the MII clock configurations in the driver.
Regards,
POWERLINK Team,
Kalycito
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried to skip the PHY Initialization alltogether, but then the application does not enter the PreOperational 2 and goes to BasicEthernet after a short while.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am facing similar problem when running the powerlink demo between two WindowsPcs the the control not is stuck in state NmtCs Basic Ethernet.I have set the adapter settings to autonegotiate
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello everybody,
i have a question about the workflow to get the zynq emacps kernelmodule running.
What i have done so far:
Kernel : 3.19.0-xilinx (with high resulution timers on / without rt patch / native emacps driver is set as module)
OPLKKernelModule: cross compiled against the prebuild linux kernel used cmake-gui for both versions (MN/CN) with emacps driver.
demo_console: cross compiled (MN/CN) Linux Kernel Module & use syncthread is active
rootfs: demo_console (mn/cn) is placed in root and the modules are placed in /lib/modules/3.19.0-xilinx/oplkemacps(mn/cn).ko
looks ok,
This seems to be bad, the network device is silent which has been proven by wireshark.
What would be the correct workflow for using the emacps kernel module?
Regards,
Heiner
Hello Heiner,
is there an MN connected to the network respectively to your Zynq which is running the CN demo? Usually a CN enters "Basic Ethernet Mode" after some time if no POWERLINK frame from an MN was received (e.g. SoA or SoC).
Best regards,
Joerg
Last edit: Joerg Zelenka 2016-01-27
Hello Joerg,
we have the same output from the cn as above, the mn did not recognize any cn. Can we use the powerlink emacps Kernelmodule if we the RTL8211E connected to the emacps driver over mdio?
Hello Heiner,
I'm not an emacps expert so I can just guess :)
For me it looks like that edrv-emacps.c (in line 1180) is trying to initialize a Marvell phy expected at address 7 (= MARVELL_PHY_ADDR).
What is your phy's MDIO address?
Best regards,
Joerg
Hello Joerg,
my MDIO PHY address is 00001b (zybo_reference_manual). I also checked this in the schematics and in the original device tree from the vendor.
The other PHY specific register configurations seem to be correct, I reviewed this with the datasheet.
I've changed the MARVELL_PHY_ADDR = 0x01 in edrv-emacps.c and tested the fresh module on the board.
There are two new things:
1: the PHY Link & ACT LED are off after I run demo_(mn/cn)_console ( very bad )
2: when I start the MN (module / demo) i got
Seems to be a problem with the Realtek chip?
Thanks and regards,
Heiner
Hello Heiner,
I don't have the Zybo or any other board with exactly that Realtek chip with me.
In order to debug your Realtek chip configuration you can use mdioPhyRead() to read out the phy registers and compare the settings with the data sheet.
Or as a workaround you can skip the mdioPhyWrite() calls in edrv-emacps.c temporarily, then the phy stays in its powerup configuration. In order to force the phy to enter 100 Mbps half-duplex connect it to a hub.
We are looking forward to a more generic solution which supports the Zybo board as well - currently the edrv is implemented for ZC702 devboard. So we are very thankful for your observations!
Best regards,
Joerg
Hi Joerg,
since Heiner and I are working together, I've also fiddled with this problem. Today I took the approach, that you also recommended by reading the PHY register. I decided to write to the PHY register the configuration to operate at 100Mbps in Full Duplex without Auto-Negotiation (since this overrides the 100Mbps at some point and I wanted to try it with the guarantee to have 100Mbps enabled). I still don't get anything returned to the network by the board, but it does seem to respond to the frames beeing broadcasted by the MN:
After the initialization is done, all the program does is continuously posting the pdoklut_getChannel() message. I would suspect, that this is a kind of response to the SoC frame being sent by the MN, since this behaviour is only observed, after a MN has gone active. From what I understand this should not be repeated continuously, since the state says something about PreOperational and should probably only entered for a short while before becoming operational. Could there be a clock timing problem or similar? If not, could you hint me at something, where I should look in particular going onward?
Hello Kevin,
I recommend to set the phys to 100 Mbps half-duplex (generally it could work with full-duplex, but just to be sure). Don't forget to conduct a software reset (msb in control reg) of the phy after you changed the speed, duplex mode and auto-negotiation bits! Also make sure that you do not enable isolate mode or loop back :)
From the log you shared it is very likely that the MN's frames are received correctly, because a CN enters the PreOperational states if a POWERLINK frame is received - PreOperational 2 is entered if the MN sends SoC frames (CN has received SoC:
NmtEventDllCeSoc
). Your CN does this correctly!The
pdoklut_getChannel()
calls indicate that your CN handles PDOs, either because it receives PReq frames from the MN, or it prepares the PRes frame for transmission, or both. So it's valid behavior thatpdoklut_getChannel()
pops up continuously!I would suggest that you connect the MN and CN to a hub (this forces 100 Mbps half-duplex). In addition connect a PC with a network interface card (disable TCP/IP for this NIC) and use it to trace the POWERLINK network with Wireshark. If needed, you can share the trace with us.
Best regards,
Joerg
Hi Joerg,
I have set the PHY's registers according to your recommendations. I'm not sure about the necessity to reset the PHY because on the one hand it does not work, i.e. if I set the reset bit, it does not clear itself and the application goes into BasicEthernet mode after a short while and on the other hand, the register documentation of the PHY states that all registers of the CTRL register would be reset to default values, which also doesn't work, as I have tried this (skipping the mdioPhyWrites) as well and the application goes into BasicEthernet here too.
Anyway, if I set the CTRL register to operate at 100 Mbps and Half-Duplex manually, the same behaviour as before is observed. The only thing I can see in the Wireshark is an SoC frame alternating with an SoA frame. In the SoA frame there is additional Info given in certain intervals (In the info, it states: tgt = 1 (or one of the other numbers 32, 110, 253 - which I think come from the predefined .cdc file) and IdentRequest).
This all ocurred with the Zybo being the CN and the PC being the MN, both connected to a switch, which is not connected to any other network. If I try to run the Zybo as MN, the same behaviour Heiner posted before ("veth_xmit: frame passed to DLL") occurs.
Do you have any further ideas? At the moment I cannot shake the feeling that either I am making some very stupid mistakes, or that the application/hardware just has fun to mess with me.
Hello Kevin,
I would highly recommend using a hub instead of a switch - this simplifies everything :)
It looks like that the switch is the one having fun :)
Best regards,
Joerg
Hi Joerg,
due to the lack of a hub, I tried this with a direct connection with a crossover adpater in between, but the result is still the same. Can you recommend any other way to fix this?
Hi Kevin,
what speed and duplex mode is negotiated if you connect the Zybo directly with the PC (= MN)? Have you checked with Wireshark if there is any frame from the Zybo (IdentResp, PResp, ...)?
Maybe you can obtain a network card for the PC which allows setting the link speed and duplex mode to 100 Mbps half-duplex?
Of course the last possibility is to debug the phy registers with referencing to the datasheet...
Best regards,
Joerg
Hi Joerg,
thanks for the hint, as I am not 100% certain about which settings the network interface used. In my mind I was still thinking about the hub, which would have provided the required settings (Hopefully) by default. I'm not in the office today, but I will check on this as soon as I get back on monday. I think adpating the correct network settings on the Linux workstation (MN) with ethtools or similar should do the trick.
Hello Kevin,
I had a quick look at the ZYBO reference manual and I don't see any special initialization settings for the RealTek Phy required.
Have you already checked the driver without configuring the PHY i.e. skipping the mdioPhyWrite() in the initOnePlatformDev() routine as suggested by Joerg?
The management interface to PHY do require a clock for which configuration is controlled by the MDIO interface clock (MDC) in the network configuration register EDRV_NET_CONFIG_REG. In the current implementation the driver configures the MDC to operate for 100Mb/s. I am not sure if it is possible to control the MII clock configurations in the driver.
Regards,
POWERLINK Team,
Kalycito
I have tried to skip the PHY Initialization alltogether, but then the application does not enter the PreOperational 2 and goes to BasicEthernet after a short while.
I am facing similar problem when running the powerlink demo between two WindowsPcs the the control not is stuck in state NmtCs Basic Ethernet.I have set the adapter settings to autonegotiate