• State Resolved
  • Locked Locked
  • Replies 26 replies
  • Subscribers 33 subscribers
  • Views 4872 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

RML57L Lauchpad XL2 FREERTOS+UDP demo

David Deschenes
Prodigy 190 points
Other Parts Discussed in Thread: HALCOGEN

Does someone have a simple FREERTOS+UDP project combining the RM57L on the Launchpad XL2 eval board.

I've successfully run the LwIP demo on the board but can't seem to get the FREERTOS+UDP up and running. The PHY looks like its powered and I get the eNetworkEventUp event but transmitting UDP packets never shows up in wireshark and I never receive any Rx interrupts. It feels like a pinmux setting is incorrect but I can't find it.

I'm using Halcogen 04.05.01/CCS  Version: 6.1.1.00022/ FreeRTOS+UDP V1.0. Project attached.0434.LaunchPad.zip

  • 0
    TI__Guru 68960 points

    Hi David,

    Not that I'm aware of - but if you get this up and running and post it for others - that would be awesome.

    If you think it's a pinmux issue,  one thing you could do is dump the memory  (save to a text file)  of the IOMM module from the working

    LWIP demo and the not working FREERTOS+UDP demo and then diff the two files to quickly identify where the difference may be.

    In the *memory* view of CCS you can save memory ranges to a file in various formats.

    Thanks and Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    Prodigy 190 points

    Thanks, good tip, and doing a diff showed no differences. It's nice to exclude that possibility.

    I think I'll try the same on the interrupt modules.

    I should also note that since my original post I've also done the internal loopback test on the PHY successfully. Unfortunately I don't have a CAT6 loopback to do the external PHY loopback test (maybe I'll order one now).

  • 0 in reply to David Deschenes
    TI__Guru 68960 points
    Super - that sounds like a lot of progress.

    Does your wireshark setup show you any traces w. the LWIP demo?
    It could be just a setup issue with wireshark - see
    wiki.wireshark.org/.../Ethernet
    if you haven't looked at this before.

    We've been using an inexpensive GS105E managed switch with port mirroring and it works well for snooping the launchpad ethernet traffic.
  • 0 in reply to Anthony F. Seely
    Prodigy 190 points

    Yes with wireshark I see traffic with the lwip demo and the webpage.

  • 0 in reply to David Deschenes
    Prodigy 190 points
    Looks like I've turned on the Loopback at the EMAC level (in halcogen). Clearly I didn't understand that this would cut it off from PHY. I've disabled that in the halcogen and I'm seeing Rx interrupts now. Still not seeing my UDP outbound messages on wireshark. I'll focus on that now.
  • 0 in reply to David Deschenes
    Prodigy 190 points
    It's interesting the packets that I receive have the correct packet length but the curr_bd->bufptr doesn't actually have any data, it's all zeros. Must but something in the DMA setup...
  • 0 in reply to David Deschenes
    Prodigy 190 points
    Could I be tripped up by the MPU? See e2e.ti.com/.../449907 which states that the EMAC/DMA is accessing memory in user mode. If I look at the Halcogen MPU page the 0x08000000 is PRIV_RW_USER_RO_NOEXEC, for some reason none of these settings can be modified on that page.
  • 0 in reply to David Deschenes
    TI__Guru 68960 points

    That could be a problem.

    The lower priority MPU settings in HalCoGen/FreeRTOS are hardcoded,  but you can override them with higher priority MPU regions.

    So you could pick out a section of internal SRAM to use for your mac's buffers,  Make a higher priority MPU regioin turn on and override the

    attributes for this region so that they are accessible with USER mode rights.

  • 0 in reply to Anthony F. Seely
    Prodigy 65 points
    I am also really interested in this demo application. Right now I have everything running without FreeRTOS but it would be highly appreciated if FreeRTOS would work together with UDP
  • 0 in reply to Stefan K
    Prodigy 65 points

    has someone already been able to get udp with freeRTOS running on this hardware? so far I have no luck

  • 0 in reply to Stefan K
    Prodigy 190 points

    Not yet. Currently I'm suspecting the MPU blocking the DMA transfers from the EMAC, unfortunately I'm probably not going to get back on this till later this week and possibly not till next week.

  • 0 in reply to David Deschenes
    Prodigy 65 points

    Thank you for your reply. Could you bee so kind to upload your current demo project so that I can also look into what your current problem is? I am sill unable to get the loopback running.

  • 0 in reply to Stefan K
    Prodigy 190 points

    2072.LaunchPad.zip

    Here it is, it's not actually in loopback mode currently, in fact all its doing is flash an LED on the launchpad and listening to broadcast messages. Rx interrupts are being raised by the EMAC and the packet length is correct but I don't get any data in the HL_emac::pbuffer_array. Having said that with the debugger I do see packets in the memory, it just seems like never where the active_head is pointing to. I've also interrogated the nmpu and found no errors which was were I suspect the problem is.

  • 0 in reply to David Deschenes
    Prodigy 190 points

    0066.LaunchPad.zipI'm getting closer, creating an MPU region 12 with USER RW at the starting address to the HL_emac::pbuffer_array seems to have helped, I also had a bug in my HL_notification code where my memcpy had source and destication inverted. Now I need to implement my xNetworkInterfaceOutput so that responses are tranmitted properly.

    Updated project attached.

  • 0 in reply to David Deschenes
    Prodigy 190 points
    Soooo close... right now I'm responding to pings but with all zeros begin transmitted (as seen on wireshark).
  • 0 in reply to David Deschenes
    TI__Guru 68960 points
    David,

    Sorry if we missed this. Where are your data buffers stored for transmit?

    It looks like your internal SRAM is configured to be 'Write-Back' cached. (as hard-coded for the FreeRTOS HalCoGen project type).

    If you put the EMAC transmit buffers in that type of memory, you need to flush them from the cache before submitting the descriptor to the EMAC. The EMAC's DMA can't read into the cache of the R5.. So you need to force the R5 to write back the data from it's cache to the L2 RAM where the EMAC *can* read from.

    The other option is to make an area marked 'Write Through' in the internal SRAM .. You can use one of the higher priority MPU regions and map a subset of the 512K internal RAM as write through - then make sure that your buffers are linked into this region. (will take some linker command file work).

    -Anthony
  • 0 in reply to Anthony F. Seely
    Prodigy 190 points
    Yours is a timely/welcom reply since you've confirmed what I just observed: If i disable caching in the Halcogen I see the data transmitted correctly.
  • 0 in reply to David Deschenes
    Prodigy 190 points

    Disabling the cache and turning down the freertos tick rate has helped, I've not got ping from my host replied to but no without issues

    Ping statistics for 192.168.1.11:

       Packets: Sent = 241, Received = 237, Lost = 4 (1% loss),

    Approximate round trip times in milli-seconds:

       Minimum = 1ms, Maximum = 13ms, Average = 5ms

    Also it eventually dies in the dataEntry/phantomInterrupt, copying the LR into the PC usually lands me in the OS_list code. So clearly there is still work to do but progress none the less.

    2514.LaunchPad.zip

  • 0 in reply to David Deschenes
    Prodigy 65 points

    looks promising. thanks a lot for sharing your work with you. I hope I can return the favour some day :)

  • 0 in reply to Stefan K
    Prodigy 190 points

    Can anyone confirm that the EMAC has a minium transfer size? I've observed that ARP request will only be sent out if they are padded out to 60 bytes (not the default 42 bytes).

  • 0 in reply to David Deschenes
    TI__Intellectual 1595 points

    Hi,

    The minimum number of databytes  that can be transferred in an ethernet frame is 46 bytes(mimimum packet length including the header(dest,src and length) is 60).Hence packet has to  be padded if it is of lesser size  than the mimimum packet size.

    See section Ethernet Frame Format in the TRM for the device for more infromation.

    Regards

    Manoj

  • 0 in reply to Manoj R
    Prodigy 190 points

    Thanks for that. One last thing that I'd like to mention that was not in my last upload but is required:

    In emacRxNotification:

    pxNetworkBuffer = pxNetworkBufferGet( packetLength );

    must be replaced by

    pxNetworkBuffer = pxNetworkBufferGetFromISR( packetLength );

    otherwise the application, sooner or later will crash. I've run it over night now with this change:

    Ping statistics for 192.168.1.12:
    Packets: Sent = 60246, Received = 60165, Lost = 81 (0% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 30ms, Average = 6ms

  • 0 in reply to David Deschenes
    TI__Intellectual 1595 points

    Can you share the source code so that I can reverify it here.

    Regards

    Manoj

  • 0 in reply to Anthony F. Seely
    Prodigy 65 points
    how can we flush the emac transmit buffer before submitting the descriptor to the EMAC?
  • 0 in reply to Stefan K
    TI__Guru 68960 points
    Stefan,

    I think you want to read 31.2.11.6 Receive Channel Teardown and 31.2.12.2 Transmit Channel Teardown in SPNU562.
    Let me know if that covers the question. If so it should be pretty simple..
  • 0 in reply to Anthony F. Seely
    TI__Guru 68960 points
    Stefan,

    Sorry if I misunderstood your question.

    What I answered (teardown) is what you do if you have already submitted buffers to the EMAC for processing but want to flush them (so that they do not actually get transmitted).

    If what you want to do is flush the transmit buffers out of the data cache of the processor - then the answer is different.

    First, you can avoid needing to flush the transmit buffers from the data cache by configuring the memory area in which the buffers are linked as 'write-through' type. If you do this, then as you write to the transmit buffer, if the buffer is in cache the cache will be updated - but also the data will be written to the L2SRAM at the same time. The L2SRAM is what will be read by the EMAC.

    You can also explicitly manage flushing the cache - for that you can look at the CPU manual for guidance - but most people do the former suggestion because it's simpler.

    Best Regards,
    Anthony