CCS/MSP432E401Y: SimpleLink SDK missing libraries?

Hello Robert,

I recognize those highlighted paths and header files from TivaWare. Are you using an example based off TivaWare?

Thanks

ki

I can't be sure. I downloaded the example from he link below, then placed it into an empty driverlib project that I imported from the SDK.

https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/908/blinky.c

The link was a direct download from a google search so I got nothing besides the blinky.c file. I believe it was originally based on code in the MSP432E4 Driverlib API Guide (which I am currently failing to find a link to but I will add it if it to this thread when do).

UPDATE: I just found it. I believe it is originally based on the EMAC example from the MSP432E4 Driverlib API guide at this link

https://dev.ti.com/tirex/explore/node?node=AOD4LXqFA8XEr21FehvtQA__J4.hfJy__LATEST

Thank you for the prompt response, I really appreciate it.

Robert Gardner

Robert Gardner said:

e2e.ti.com/.../908/blinky.c

The "908" is the E2E forum typically used for Tiva. Hence this example is likely derived from TivaWare.

Since the MSP432E401Y is related to the TM4C1294 Tiva part, the example will likely be compatible. But that particular source file is dependent on TivaWare.

If you are looking for a blinky type example, why not use the one that comes with the SDK?

https://dev.ti.com/tirex/explore/node?node=ABOaKNF1WvfflV8Q6ffwQg__J4.hfJy__LATEST

Thanks

ki

Robert Gardner said:

I believe it was originally based on code in the Driverlib EMAC API guide documentation (Which I am currently failing to find a link to but I will add it if it to this thread when do)

That is linked from the TI Resource Explorer under Software -> SimpleLink MSP432E4 SDK -> Documents -> DriverLib -> DriverLib API Guide.

The blinky.c from the forum post, specifically the source code I linked, was adapted to make use of ethernet. My goal is to send my PC a message via UDP from the E4. Up to this point, my team and I had been using the udpecho example from the SDK but after months without progress on getting that example working, we are exploring other options and examples to build from.

I don't really care about getting an LED to blink, I only want to send a UDP segment to my PC. Which, the blinky.c I included in my post had been adapted to do using the EMAC example in the dirverlib API guide I linked and that Chester Gillon also found and provided a link to

Yes, that is exactly what I was referring to. Thank you

Robert Gardner said:

I have highlighted the libraries that I can not find in the screenshot below.

As already mentioned by Ki, it looks like blinkly.c came from a program for a Tiva TM4C129 device using TivaWare.

While the TM4C129 and MSP432E4 devices have the same peripherals, the supporting SDK's from TI are different. I.e. taking an example source file which was developed under TivaWare might not compile without change under the SimpleLink MSP432E4 SDK.

I see.Thank you both.

It sounds like making use of that particular Ethernet altered blinky example might not be my best option.

Do you believe that using the Driverlib API Programming Example from EMAC (the one in the link you provided in your previous reply) would be usable for establishing UDP communications between my MSP and my PC? My team and I have been eandeavoring to make use of it but haven't made solid progress with it yet

Robert Gardner said:

Do you believe that using the Driverlib API Programming Example from EMAC (the one in the link you provided in your previous reply) would be usable for establishing UDP communications between my MSP and my PC?

1. Use the Driverlib API to get the EMAC to send/receive frames directly. Your program would have to implement the IP layer to send/receive frames containing UDP packets, and need to implement ARP to get the MAC address of the PC. This is "No RTOS". I can't recall seeing any TI examples which operate at this level.
2. Use lwip. This is "No RTOS". lwip implements TCP or UDP. The Simplelink MSP432E4 SDK has an lwip example for a TCP Webserver application under Examples -> Development Tools -> MSP432E401Y LaunchPad -> lwip -> ethernet-based_io_control. The example lwipopts.h would need changing to support UDP.
3. Use the TI-RTOS Network Services. The Simplelink MSP432E4 SDK has a UDP example under Examples -> Development Tools -> MSP432E401Y LaunchPad -> Network Services -> udpecho -> TI-RTOS
4. Use the FreeRTOS Network Services. The Simplelink MSP432E4 SDK has a UDP example under Examples -> Development Tools -> MSP432E401Y LaunchPad -> Network Services -> udpecho -> FreeRTOS

Will your project benefit from a RTOS or not, as that could help select which of the above options to use?

We need to use FreeRTOS as a part of our design. We started with the fourth option you've described but had no luck. Since yesterday, we've managed to get the Driverlib API Emac example (the first item you listed) working, incorporated into our freeRTOS program as its own thread, and have successfully sent UDP segments to the PC. Our final roadblock is that we can't send things of the size we would like.

We haven't figured out the exact threshold but its somewhere between 1000-2000 characters when the program fails to send.

The only thing we need to send is a string consisting of slightly more than 4000 characters and our project will be complete. If you have any suggestions I'd love to hear them. We've mostly been playing around with the various flags that are available for use in EMACConfigSet.

Also, you and Ki have been immensely helpful, prompt, and informative with your responses. If there's any way for me to give both of you points, or even extra points, please let me know so I can do so. You've both been incredible.

Chester Gillon said:

I am not sure if this explains the problems you were having, but will see if a configuration change is required to send fragmented UDP packets of if this is a bug.

    mss -= SockGetIpHdrSize(hSock) + UDPHDR_SIZE;   /* Sub off IpHdr & UdpHdr */

    if( size > mss )
    {
        error = NDK_EMSGSIZE;
        goto UDP_EXIT;
    }

Where:

• size = 1473
• mss = 1472

The callstack was:

UdpOutput(void *, unsigned char *, int, int *)() at udp.c:166 0x00007D78
SockSend(void *, unsigned char *, int, int, int *)() at sock.c:1,902 0x0000AF68
NDK_sendto(void *, void *, int, int, struct sockaddr *, int)() at socket.c:1,346 0x00012E5E
SlNetIfNDK_sendTo(int, void *, void *, unsigned int, unsigned int, struct SlNetSock_Addr_t *, int)() at slnetifndk.c:1,976 0x0000641A
SlNetSock_sendTo(int, void *, unsigned int, unsigned int, struct SlNetSock_Addr_t *, int)() at slnetsock.c:1,338 0x000150A4
sendto(int, void *, unsigned int, int, struct SlNetSock_Addr_t *, int)() at socket.c:275 0x0001A250
echoFxn(void *)() at udpEcho.c:143 0x00004DDC

At the end of the UdpOutput() function there is:

    /* Send the packet */
    error=(int)IPTxPacket(pPkt,SockGetOptionFlags(hSock)&FLG_IPTX_SOSUPPORTED);

UDP_EXIT:

Where the IPTxPacket() function has the ability to send a fragmented packet. Therefore, it appears to be a bug in the NDK with simplelink_msp432e4_sdk_4_20_00_12 whereby the UdpOutput() function can report an NDK_EMSGSIZE error if the packet payload size exceeds the MSS, prior to calling the IPTxPacket() function which will fragment the packet.

Hopefully someone from TI can confirm if this is a bug.

This thread has been brought to the attention of the device experts. They should be able to provide more input.

Thanks

ki

Chester Gillon said:

Therefore, it appears to be a bug in the NDK with simplelink_msp432e4_sdk_4_20_00_12 whereby the UdpOutput() function can report an NDK_EMSGSIZE error if the packet payload size exceeds the MSS, prior to calling the IPTxPacket() function which will fragment the packet.