• State TI Thinks Resolved
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 14 replies
  • Answers 1 answer
  • Subscribers 85 subscribers
  • Views 624 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28388D: Ethernet driver callbacks

Arjan Oskam
Intellectual 510 points
Part Number: TMS320F28388D
Other Parts Discussed in Thread: C2000WARE

Hello there,

I'm looking into the Ethernet driver in driverlib_cm, trying to port the lwIP stack to an application with SYS/BIOS. As a starting point for learning about the Ethernet driver and lwIP I'm also looking into the enet_lwip examples. The code is not easy to comprehend, but I'm beginning to get the picture. And I have a few questions:

1. Is there a detailed API reference for the Ethernet driver? I only found this doc, and it doesn't provide much detail:
dev.ti.com/.../ethernet.html

2. The pfcbGetPacket() callback function must return a pointer to a filled Ethernet_Pkt_Desc struct, with its dataBuffer located in a piece of application memory (array Ethernet_rxBuffer in the example code). But there's only a single Ethernet_pktDescriptorRX struct defined, will that not get overwritten with subsequent calls to the callback? I would sooner expect a pool (array) of descriptors.

3. If I look at how the pfcbGetPacket() callback is used in the ethernet.c code, there's also a check for a NULL result in case there's no free memory in the application's Ethernet_rxBuffer. However the default Ethernet_getPacketBuffer() implementation (which is also used in the enet_lwip example) always returns a pointer to the buffer, there's no check if it's actually free (rxBuffIndex merely toggles between 0 and 1). Couldn't that cause Rx data to be overwritten? Or am I missing something?

4. The pfcbRxPacket() callback function is called after packet Rx is complete. I suppose the 'Ethernet_Pkt_Desc *pPacket' argument is a pointer to the Ethernet_Pkt_Desc struct that was acquired in the call to pfcbGetPacket()? So I think this would also be the place to 'free' the memory that was used by the descriptor's dataBuffer, right?

5. Looking at the default Ethernet_receivePacketCallback() implementation, the pfcbRxPacket() callback is expected to return a pointer to a new 'free' descriptor, just like pfcbGetPacket(), correct?

Thanks and kind regards,
Arjan

  • 0
    TI__Mastermind 34765 points

    Arjan, 

    Will get back to you on your queries in the next couple of days.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    Any update on this subject?

    Thanks,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Mastermind 34765 points

    Arjan,

    Sorry for the late response.

    Regarding the driverlib API guide, it will be updated to include description of the APIs in the ethernet driver.  This will be  available in the next C2000Ware release. 

    Regarding other queries, wlll get back to you.  

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    Any word on those other queries?

    Kind regards,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Mastermind 34765 points

    Arjan, 

    Sorry haven't had the time to look into it as I am busy with a release. 

    Will get back to you by next week.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    Hope you can find some time to look into this. Meanwhile I have an additional remark related to nrs 3 and 5 above:

    6. In enet_lwip's Ethernet_receivePacketCallbackCustom() I noticed it returns the same Ethernet_Pkt_Desc pointer it received. So basically it uses always the same half of Ethernet_rxBuffer[]. Is this intentional, and if so, why?
    The default Ethernet_receivePacketCallback() function in ethernet.c calls Ethernet_getPacketBuffer() at the end, to switch to the other half of Ethernet_rxBuffer[]. Although I still would have expected 2 separate descriptors, each with its own dataBuffer (see my question nr 2 above).

    Kind regards,
    Arjan

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    I hope you haven't forgotten about my queries.

    Kind regards,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Guru 50531 points

    Arjan,

    Just checking if you had a chance to look at the latest release of C2000Ware 4.02.00.00. 

    Regards, Santosh

  • 0 in reply to Santosh Jha
    Intellectual 510 points

    Hello Santosh,

    I had a quick look. As far as I can see there have been no changes to the lwIP lib and examples, as well as the driverlib_cm Ethernet driver files.

    I see the documentation for the Ethernet module in the CM API Guide was updated. But this is mostly auto-generated from source code comments.

    So unless I missed something, I still don't have an answer to my queries.

    Kind regards,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Mastermind 34765 points

    Arjan,

    Apologies for the delay in responding on this. 

    The current implementation of the lwip port layer will need some adaptation and updates to support an SYS/BIOS or a multi-threaded system and agree with you that the code is difficult to comprehend .  

    Unforutnately there is no plan to work on adding SYS/BIOS or RTOS support to LWIP example at this point.

    Best Regards

    Siddharth

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    Although I used the enet_lwip examples as a starting point, my questions are not really related to lwIP or SYS/BIOS, but only to the C2000WARE driverlib_cm Ethernet driver and the expected behavior of the callback functions.

    Surely it must be possible to provide some clarification there?

    Kind regards,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Mastermind 34765 points

    Arjan,

    The ethernet example 'ethernet_ex1_basic_tx_rx_loopback' would have been a  good starting point to understand the ethernet driver. 

    Here are the clarifications to your questions.

    2. Yes, there will be a queue of descriptors

    3.  The Ethernet_getPacketBuffer function returns  a packet descriptor. In case of the enet_lwip example,  the Ethernet_rxBuffer[] is segregated into multiple packets based on ETHERNET_NO_OF_RX_PACKETS value , hence it will store the packets at different location for every packet. A check can be added to make sure that buffer is available.

    4. The pfcbRxPacket callback function is the Rx packet completion callback function, it is meant to pass the pointer to the packet  for the application and the application can handle it and set the data buffer free

    5. The default Ethernet_receivePacketCallback implementation is a place holder and  expected to return a pointer to a new descriptor.

    Best Regards

    Siddharth

     

  • 0 in reply to Siddharth Deshpande
    Intellectual 510 points

    Hi Siddharth,

    Thanks for your replies, I still have a question #6 open though in one of my replies above...

    I did have a look at the 'ethernet_ex1_basic_tx_rx_loopback' example in the beginning. But the name says exactly what it is, a very basic example.

    What I'm missing is a more real-world example, fully using the DMA channels and handling line interruptions and other faults. Especially the DMA part and why and how to configure the related buffers lacks some explanation.
    I noticed during initialization of the Ethernet driver it calls the Ethernet_getPacketBuffer callback 8 times (ETHERNET_DESCRIPTORS_NUM_TX_PER_CHANNEL, the default numBD setting). In the enet_lwip example and the other examples this means when ETHERNET_NO_OF_RX_PACKETS is less than 8 (like it is in the examples) then multiple DMA descriptors will point to the same piece of memory (Ethernet_rxBuffer).
    Is that the correct behavior, or is it a potential bug? I don't know because there's no explanation in the comments.

    I have spent a lot of time analyzing the Ethernet driver code trying to figure out how it is supposed to work. The simple examples are clear enough, but when trying to create a more complex application (especially with RTOS) that wants to make full use of the available hardware peripherals it becomes a real challenge.

    At the moment my application (SYS/BIOS with lwIP, using TCP, UDP, and MQTT) seems to work OK, although nut fully stress-tested yet. But I still have doubts about some parts of my implementation, like the DMA descriptors I mentioned. I feel there's more performance available in the hardware than I'm currently able to use.

    Kind regards,
    Arjan

  • 0 in reply to Arjan Oskam
    TI__Mastermind 34765 points

    Arjan,

    Agree, currently we don't have any RTOS based example for ethernet. 

    Will check and add more information regarding the buffer configuration and descriptors.

    Best Regards

    Siddharth