Closed fsabbatini89 closed 7 years ago
Have you run CTT?
I'm sorry. I don't have the tool as I am not a member of the ecat group
Ok, no problem.
How does the LAN9252 issue express itself? I've implemented a LAN9252 port for our RTOS, it pass CTT, so I would like more how it affect the behavior.
So i have implemented a driver for LAN9252 myself using the SQI interface. Everything works great until i use a long OD. I use twincat master and wireshark to sniff the packets. When i try to retrieve the dictionary online a SDO_getodlist request (function) fires. So far so good. After that, as the dictionary is bigger than the mailbox size (128 bytes by default), an incomplete flag is set in the COE header of the SDO_getodlist mailbox. After that the function SDO_getodlistcont has to be called in order to finish sending the OD, but it will never be called as the master never writes anything again, it just sits there waiting for the slave to finish sending its dictionary until the masters just times out. The return 1 fixes the issue.
Then after the first GET OD LIST request from the twincat master, i tried to do another GET OD LIST request and it hangs. I "reload the devices" in twincat in order to reset the slave ESC and i can get the od list once again, but only once! Looking at the ECS registers i found that the bit 1 (interrupt read) of the register 80Dh (status register of the SM1 supposing sync manager 1 is using as and "in mailbox" for the master) is stuck even after writing a byte in the buffer (this is what the function ESC_ackmbxread does) and it nevers clears. I discover that if a give it a little time (i am running a microcontroller at 200Mhz) it clears and everything works out ok so i decided that adding the code will do:
ESC_SMstatus (1); / while interrupt flag is set, skip mailbox process / if(ESCvar.SM[1].IntR){ return 0; }
i hope explained myself
Yes, I'll look into this. Are you aware of any LAN errata? If it is an LAN issue we should comment that in the code.
@fsabbatini89 , can you test replacing your fixes with the following
/ Check mailboxes / if ((ESC_mbxprocess() > 0) || (ESCvar.xoe > 0)) { ESC_coeprocess(); ESC_foeprocess(); ESC_xoeprocess(); }
Yes, I will try that when I get back from a trip I am doing.. it will be like in 3 weeks. But reading the code it will work to fix problem 1 but I don't think it will fix the issue with the chip.. I was reading lan9252 erratas and didn't find anything
El El mié, 15 de mar. de 2017 a las 08:55, nakarlsson < notifications@github.com> escribió:
@fsabbatini89 https://github.com/fsabbatini89 , can you test replacing your fixes with the following
/ Check mailboxes / if ((ESC_mbxprocess() > 0) || (ESCvar.xoe > 0)) { ESC_coeprocess(); ESC_foeprocess(); ESC_xoeprocess(); }
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/OpenEtherCATsociety/SOES/pull/18#issuecomment-286767212, or mute the thread https://github.com/notifications/unsubscribe-auth/AY6NUiHViApwaOxcL3A93bN35PwSKJgSks5rl_vggaJpZM4MRK0U .
-- Franco
I want you to split the PR in OD list and the LAN issue.
The OD list is confirmed. I think we could use ESCvar.xoe to conditionally return 0 or 1.
The LAN issue needs to be confirmed, I'll try to allocate some time soon to try the LAN card again. Can you somehow verify that the ackmbxread actually get through?
Added fix for fragmented COE response in 39e2e116d095dbd08cb327d54b0c7bfd721d5a12, the LAN issue is not possible to reproduce on our lan port.
fixed fragmented SDO mailbox
when using LAN9252 chip, for whatever reason (chip bug), the READ INTERRUPT remains set even after the ACK routine gets executed so the next mailbox write does not work.
the second fix is a return 1 at the end of the read interrupt ack so fragments left in the COE mailbox get a change to be sent