This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

RM57L843: EmacTransmit function

Part Number: RM57L843
Other Parts Discussed in Thread: HALCOGEN

I don't want to use the lwip Ethernet Stack so I am writing my own small Ethernet Stack.

I am using the EMAC functions generated from the halcogen in the HL_emac.c file, but when I try to transmit an ethernet packet with the EMAC transmit function it sends the first time just zeros and all following packets are  one packets behind. So I can never answer with the correct sequence number for example, because I am always one packet to late.

Does anybody have the same problem? Is there a method to debug the transmit channel registers?

Thank you

  • Hello Daniel,

    I have forwarded your post to one of our Ethernet experts. They should get back to you soon.
  • Hi Daniel,

    Have you debugged where the "first time zeros" originates? Is this something from your application?
    You retvalue is true from EMACTransmit() indicating valid data sent?
    What do you have on the other end of the network listening to the incoming traffic?

    Lali
  • Hello Lali

    I think the first zeros come from the initialisation of the pbuf.
    The buffer in my application seem obviously correct. I print them out and watch them in the debug mode.

    The retvalue is true. I also debugged the adress of the descriptor Pointer in the TX0HDP Register:

    void EMACTxHdrDescPtrWrite(uint32 emacBase, uint32 descHdr,
    uint32 channel){
    HWREG(emacBase + EMAC_TXHDP(channel)) = descHdr;
    }

    The Value of descHdr is 0xfc520000, the channel is 0.
    Before the function call: EMAC_TXHDP(0) is 0x0
    After the function call: EMAC_TXCP[0] is 0xFC520000

    so it seems to work but the controller does not send the data immediatly or it sends the wrong data.

    I measure the MII data with an logic analyzer and capture the ethernet frames with wireshark.

    For example:

    - RM57 starts
    - I send an arp request for 192.168.100.1
    - the logic analyzer shows 60 zeroes and the 4 Bytes checksum, wireshark does not capture a packet
    - Then I send an arp request for 192.168.100.2
    - the logic analyzer shows the correct ethernet Frame and ARP Packet but with the request for 192.168.100.1 and wireshark also shows the Request for 192.168.100.1

    If I execute the EmacTransmit() two times successively, the controller also sends two times zeroes at the first time and two arp requests for 192.168.100.1 at the second time.

    It seems for me that the DMA does not send the data.

    It is very strange and tricky to debug. I hope somebody is able to help me.

    Thanks and Regards,

    Daniel
  • I still have the same problem, has no one any idea?

    I suppose there is a problem with the EMAC DMA unit. It seems the data are sent before they are transferred into the TX-FiFo.
    This would explain the transmission of zeroes at the first time, when the FiFo is initialized with zeroes.
  • Daniel,
    We are looking into this and shall get back to you.

    Lali
  • Hello,

    Waiting for an answer, I solved the problem myself.

    As I supposed the DMA controller of the EMAC makes the problem. The data is not copied from the RAM but from the cache.

    At the first transmission, nothing is cached and so the data is not as expected.

    First workaround was to disable the cache and it worked. But this could not be the solution.

    In the second way I changed the the MPU Region of the EMAC memory region to write-through (MPU_NORMAL_OIWTNOWA_NONSHARED) and enabled the cache again and that has also worked.

    I think this is the correct way, isnt it?

    Regards

    Daniel

  • Daniel,

    That is the correct solution. Your first option to disable the cache is OK but you give up some system efficiency in doing so. The second solution targets jus the DMA with the EMAC so it is the correct approach. I am glad that you were able to resolve it.