• State TI Thinks Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 3 answers
  • Subscribers 31 subscribers
  • Views 511 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.

MCU-PLUS-SDK-AM243X: FreeRTOS LWIP UDP echo example app fails if tcp echo is not running

Bryce Mitchell
Prodigy 30 points
Part Number: MCU-PLUS-SDK-AM243X
Other Parts Discussed in Thread: TMDS243EVM

If I set LWIP_TCPECHO_APP to zero in lwipcfg.h in the LWIP example applications, the UDP echo app will fail. I am trying to figure out why this is happening, because I don't see any reason why the udp echo app should depend on the tcp echo app. I am using mcu_plus_sdk_am243x_08_05_00_24 with either of the LWIP examples "enet_lwip_icss" or "enet_lwip_cpsw" under "examples\networking\lwip\", running on a TMDS243EVM evaluation board.

Connecting to the udp echo application with ncat from the host PC (e.g. ".\ncat -u 192.168.1.100 7").

If tcpecho is running, then I see my lines echoed in ncat, and I see a message in the console from udpecho saying "got <my message>" showing that it is receiving the packets. I also see messages in the console continuously reporting the CPU load.

If tcpecho is disabled, then I do not see my lines echoed in ncat, and although I see the first line in the console saying "got etc.", after the first message the console stops printing anything including the CPU load.

From what I can tell from the debugger the udpecho app is able to receive the first message but enters some kind of fault when it tries to send the reply back, so it never gets to receive another message. This fault does not happen if the tcpecho app is also running.

Any suggestions would be appreciated.

  • 0
    TI__Mastermind 35982 points

    Hi Bryce,

    We are looking into this issue. Please expect a response by early next week.

  • 0
    TI__Genius 12571 points

    Hi ,

    From my analysis, the code enters reset and tries to perform mpu_init, where we get a data abort.

    I was able to replicate the issue on my end, I have raised a bug which is being looked into.

    Meanwhile, I suggest you use examples/networking/lwip/enet_cpsw_udpclient or examples/networking/lwip/enet_cpsw_tcpclient  examples for TCP or UDP functionality. 

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    Hello Shaunak,

    I have looked at the examples you suggested, but for my application we are intending to use the socket API. I tried the example in examples\networking\lwip\enet_cpsw_udp_igmp but I am seeing strange behavior with this one as well. Using ncat, as before, I see it echo the first message I send, but subsequent messages return gibberish text instead.

    test message
    test message
    another example
    ÖYfªÖYfªÖYfªÖYfª

    The example seems to receive the messages on the target just fine:

    Packet recieved
    Client: test message
    Echo pkt completed

    Packet recieved
    Client: another example
    Echo pkt completed

    Are you able to reproduce this as well? Or have any suggestions about why it may be happening?

    Thanks

    -Bryce

  • 0 in reply to Bryce Mitchell
    TI__Genius 12571 points

    Hi Bryce,

    For the examples\networking\lwip\enet_cpsw_udp_igmp, I was unable to reproduce the issue on my end, I am able to see all the messages being echoed back to the NCAT terminal, as well as able to see the prints in the terminal. I tried to send around 20 messages, all were echoed back successfully.

    Q1. Can you please confirm if there are no changes made by you in the LwIP library under source/networking/lwip/.*

    Q2. Do you observe this behavior in the out-of-box example or after making some changes in the Example or the LwIP library?

    Q3. Also, can you scrub/clean and rebuild the project, connect the UDP IGMP server to port 2638 and try to send messages?

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    I have just tried building from a newly installed SDK to make sure there are no changes. I am still seeing the same behavior. I am connecting to the example using ncat with the command ".\ncat.exe -u 192.168.1.100 2638". I always see the first message echo back correctly, but all subsequent messages are corrupted:

    test
    test
    message
    ÖYfªÖYfªok
    ÖY

    What version of the SDK are you using? I am using 08_05_00_24 as in the original post. Are there any other versions I should check to compare?

  • 0 in reply to Bryce Mitchell
    TI__Genius 12571 points

    Hi Bryce,

    Can you share your debug.out file and the map file for the project? Need to debug using your .out binary since I am still unable to reproduce the issue on my end.

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    I can share them. What is the best way to upload them? I tried to drag and drop them on the reply window, but it did not succeed in uploading.

  • 0 in reply to Bryce Mitchell
    Prodigy 30 points

    I have attached them as a zip. Let me know if you need any more files than this.

    enet_cpsw_udp_igmp.Debug.ti-arm-clang.zip

  • 0 in reply to Bryce Mitchell
    TI__Genius 12571 points

    Hi Bryce,

    I was able to reproduce the issue. This is a known cache coherency issue in LwIP Stack UDP APIs.

    The fix is to Cache Write back and Cache invalidate the buffer before you reuse it every time.

    The official fix is a part of 08_06 release of the MCU_PLUS_SDK. Meanwhile, you can follow the image below and make required changes in "app_udp_igmp_server.c", rebuild the example and it should work as expected.

    Regards,

    Shaunak

  • 0 in reply to Shaunak Deshpande
    Prodigy 30 points

    Thank you, Shaunak, that did resolve the issue. Are there any other cases where this fix is needed?

    Also, is there any update on the original data abort issue? Right now we are working around it by starting a TCP server before any UDP traffic.

  • 0 in reply to Bryce Mitchell
    TI__Genius 12571 points

    Hi Bryce,

    The fix is mostly needed with LwIP UDP socket APIs where you would reuse the buffer. I would recommend trying this fix whenever you face a similar issue with UDP or LwIP socket APIs.

    I have raised a bug with the internal team regarding the data abort issue being caused by device going into reset (as discussed above in this same thread). I will keep you updated on further advancements, if any.

    Regards,

    Shaunak