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.

TMS570LC4357HDK Ethernet

Other Parts Discussed in Thread: HALCOGEN, TMS570LS3137, TMS570LC4357

Hi,

I recently bought TMS570LC4357HDK and I am trying Ethernet example of TMS570LC4357HDK i.e. example_EMAC_Loopback_TxRx.c and i did exactly as mentioned, however, its not working for me. I even tried to connect the board with my PC via ethernet cable and checked using wireshark tool but i dont see any data.

I would like to know if anyone has tested ethernet on TMS570LC4357HDK with PC

It would be great if i get any kind of help/advice. Thank you.

Regards,

Solomon

  • Hello:

    We have received your post and will get back to you soon.

    Regards.
  • Hi Solomon,

    Can you provide us little more info. When you mentioned not working does it mean

    1) You did not receive the data in the the receive descriptors start at 0xFC521010?
    2) Did you code come to the while(1) at the end of main function? 

    We do have a LWIP based Demo ( for you device you must use Demo v03 which can be downloaded from the end of the wiki page.) 

  • Hi Prathap,

    Yes the code came to while(1) at the end of the main function and i connected TMS570LC43HDK to a PC via CAT5 cable. My intention is to receive Ethernet packets on my PC from the development kit and i would like to see those packets on Wireshark application. All i can see on wireshark is "00", no matter what packet/data i send and it says unknown frame (Bogus Fragment). The only relevant information i can see is bytes captured which is correct and rest everything is "00".

    I also have TMS570LS3137HDK and demo code for TMS570LS3137 works perfect (with relevant Halcogen settings). But demo code meant for TMS570LC43HDK with relevent Halcogen settings does not works. I tried the example  you mentioned and it works on TMS570LC43HDK, but the simple one "example_EMAC_Loopback_TxRx.c" (i am not doing loopback, on Halcogen->EMAC->EMAC Global except loopback, i selected all). I hope i tried to convey my message, if not i will send source code and screen shots. Thank you very much

    regards,

    Solomon

  • *But the simple one "example_EMAC_Loopback_TxRx.c" does not works.
  • Hi Solomon,

    Sorry for the delay. I was not keeping well. 

    I suspect PinMUX configuration settings. Could you please send the CCS pjt along with HALCoGen project? So that I can confirm it against my settings here. Thanks! 

  • Hello Prathap,

    Thank you for your efforts. I have enclosed CCS project with Halcogen settings (inside source folder). I have also enclosed screen-shot of wire-shark. Any advice would be a great help to me, Thank you once again.

    Regards,

    Solomon0513.Test_Ethernet.zip

  • Solomon,

    Some additional thoughts...

    Did you flip the Ethernet On switch on the HDK? (S2-4?)

    With wireshark, are you directly connected to your PC or are you going through a switch. If it's a switch - then you may need to go through some of the instructions here: wiki.wireshark.org/SwitchReference.
  • Hi Anthony,

    Yes i flipped Ethernet switch on HDK (S2-4) and i am directly connected to the PC without Switch. As i mentioned earlier, this same set-up works for TMS570LS3137 HDK (with relevant settings in HALCOGEN) and i receive accurate data/payload on wire-shark.

    But for TMS570LC4357, on wire-shark (the screenshot which i enclosed) I get correct packet length but only payload/data becomes 0 which is strange. If there is some issue with pin-mux i shouldn't be getting any packet on wire-shark from HDK.

    Thank you.

    Kind Regards,
    Solomon
  • Solomon,

    Ok, I just scanned your HALCoGen project - and I see you have MII checked on the PINMUX tab - but you have unchecked the MII pins say on A14, B4, etc.

    That's the correct thing to do for the *LaunchPad* that we are about to release (and that I've started posting about) but not for the HDK. The HDK uses the pin locations that are compatible w. the older parts in the series like TMS570LS3137 and you need to use the alternate pinmux.

    I'll try that in a minute and see if it clears up anything.

    BTW I suggest checking out Linker ECC processors.wiki.ti.com/.../LAUNCHXL2-570LC43-RM57L:_TIPS
    because it's a much more stable way to build your project. It takes slightly longer to download but avoids spurious ECC errors due to areas of the Flash that you aren't using being left empty (with ECC errors) by the loader's auto-generated ECC method.
  • Solomon,

    Ok so I fixed the pinmux but now I'm seeing the bogus frame. What's interesting is that the first size of 470 matches your 'size1'.
    Will look into this a bit more to see if we can figure out what's going on.

    -Anthony
  • Thanks Anthony, it will be very helpful.

    Regards,
    Solomon
  • Solomon,

    There seems to be an issue with the buffers being located in RAM that's cacheable.    I think the CPU's writing to the data buffers but the content isn't being flushed to the L2RAM where it needs to be in order for the EMAC to pick it up.      Explains why we saw the correct length but with garbage data.  

    I disabled the cache to do a quick test - and got both packets on wireshark:

    A better way of course would be to either configure the area you are using to create the buffers as write-through (so all writes will immediately also make it to the L2RAM) or to flush the cache after the buffers are created and before submitting the head pointer to the EMAC.  

    Here's the updated project w. the simple 'cache disable' change.    Actually I speak too loosely.  I didn't disable all the caches - I just changed the attribute of the memory region covering RAM to be non-cacheable.   You could try making it write through next ...

    Also I noticed that the example code for the byte swizzling is generating a lot of instructions ..   The R5 has a "REV" opcode to reverse the bytes in a 32-bit word and not sure why our example doesn't use it - but it may make sense to eventually work this in place of the swizzle.   I ping'd our compiler expert to ask why the compiler may not be inferring the REV automatically...

    7612.Test_Ethernet2.zip

    Thanks and Best Regards,
    Anthony

  • Hello Anthony,

    Yes, this solved the problem. I can receive packets with payload correctly. Thank you.

    Kind Regards,

    Solomon