Using FreeRTOS Plus to handle UDP communications on TI Hercules

I am attempting to use FreeRTOS Plus to handle UDP communications on the TMS 570 device. In the future, I hope to implement it on the RM 57, but have not gotten that far yet.

In my initial attempts to incorporate the software onto the device, I noticed that the NetworkInterface.c file was dependent on the manufacturer of the device in question. Unfortunately, I saw nothing specifically for the TI devices I intend to work with.

My question is this: Is there software already designed for the TI Hercules devices that I can use? Or, am I going to need to derive the network interface myself to get the connection working?

If there is software already designed for this purpose, where can I find it?

Thanks!

I’m not aware of a driver for that part being available, although I do recall conversations about using +TCP on these parts before (grateful for everybody who makes their code available to the whole community!). Unless somebody else comes up with something here then it is ‘moderately’ simple (depending on your experience level) to implement your own driver. This link provides the instructions https://freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/FreeRTOS_TCP_Porting.html - if you don’t care too much about throughput you can do something really simple just by stitching the +TCP port layer functions into whatever drivers TI already provide. If you do care about throughput then I would recommend starting with something simple anyway, then once you see that working, look at how it can be optimised (using DMA, or whatever is available on the chip).

@ajsmart92

I think we are on a similar path. I skipped the TMS570 however and went directly to RM57L. I’m using TI’s LaunchXL2-RM57L development board for now.

I managed to port FreeRTOS v10.3.1 to the RM57L and have the simple two task, two LED blink test running as of yesterday.

My remaining issue with the port is that I had to disable privileded_function and privileged_data macros. Really simple to undo. With that, I have a clean complie… no errors, no warnings. I’m going to postpone working on the privilege issues for now as I haven’t dug into it.

My next step is to try and add FreeRTOS+TCP. I started looking at the details this morning. I’ve got some homework to do before I’m ready to start the port however.

I would have uploaded a .zip to FreeRTOS interactive but I haven’t been able to figure out how to register for that forum. That’s a shame because I have searched high and low for an RM57L port and have come up empty. Plenty of other people with the same issue.

Grateful if the output of any of this work can be posted to https://interactive.freertos.org if you are able to create an account (lots of issues reported there), or just by attaching to this forum thread so we can host. Thanks.

I’m one of those unable to register at https://interactive.freertos.org unfortunately.

Here’s a .zip instead.

RM57L_FreeRTOS_v10.3.1.zip (1.2 MB)

You can search for “/* TC” to see the few places I modified things to mask the privileged region issues I had.

My changes are constrained to the following files:

os_mpu_wrappers.h
os_mpu_wrappers.c

By the way, ask TI about the funky renaming of FreeRTOS files prepending “os_”. I just replicated what they had for a FreeRTOS v9.0.0 port (which what I started with).

Also search for “//TC” in hl-sys_main.c

I used #pragma diag_remark and #pragma diag_warning to mask an unavoidable warning. Don’t know if this reasonable practice, or not. I was just trying it out.

Thanks.

[text here just to make up the minimum to enable a post]

I’m proceeding with the port of FreeRTOS+TCP but am running into compilation errors that I don’t understand (CCS v9.3.0.00012).

#85 invalid combination of type specifiers

These errors are all concentrated in the following files…

FreeRTOS_DHCP.c
FreeRTOS_DNS.c
FreeRTOS_IP.h
FreeRTOS_IP_Private.h

I’ve found the link below but I’m having trouble making sense of it (I can’t find the source of the error).

https://processors.wiki.ti.com/index.php/Invalid_combination_of_type_specifiers_and_Bool

Suggestions welcome

The first error brings me to the last line of this code block in FreeROS_DHCP.c

#include “pack_struct_start.h”
struct xDHCPMessage
{
uint8_t ucOpcode;
uint8_t ucAddressType;
uint8_t ucAddressLength;
uint8_t ucHops;
uint32_t ulTransactionID;
uint16_t usElapsedTime;
uint16_t usFlags;
uint32_t ulClientIPAddress_ciaddr;
uint32_t ulYourIPAddress_yiaddr;
uint32_t ulServerIPAddress_siaddr;
uint32_t ulRelayAgentIPAddress_giaddr;
uint8_t ucClientHardwareAddress[ dhcpCLIENT_HARDWARE_ADDRESS_LENGTH ];
uint8_t ucServerHostName[ dhcpSERVER_HOST_NAME_LENGTH ];
uint8_t ucBootFileName[ dhcpBOOT_FILE_NAME_LENGTH ];
uint32_t ulDHCPCookie;
uint8_t ucFirstOptionByte;
}
#include “pack_struct_end.h”
typedef struct xDHCPMessage DHCPMessage_t;

The statement :

typedef struct xDHCPMessage DHCPMessage_t;

should not be problematic.
I think that your compiler doesn’t like the contents of the header file.
Can you tell which version of pack_struct_end.h is included? Is should be one out of: GCC, IAR, MSVC, Renesas. What compiler are you using? is the correct version being included?

@htibosch

That was it! I replaced my pack_struck_end.h and pack_struct_start.h from GCC versions and that fixed that set of errors.

Thanks!

@Todd

I had this issue as well in Code Composer Studio. The way I fixed it was by adding a semicolon after the closing bracket of the struct definition.

That resolved all of those errors, and lead me to a bunch of compiler errors with undefined functions that I needed to resolve. I was able to resolve most of them by making sure that the FreeRTOSConfig file and the FreeRTOSIPConfig files were setup correctly (I disabled TCP, so that may not apply to you).

In the end, I am to the point where there are four custom functions that I need to create to get the FreeRTOS + UDP to work with the device, but that’s going to require me to dig pretty deep into the drivers and lower level code.

@ajsmart92

Thanks! I’m past those errors and warnings now.

Sounds like we are at the same point… mapping the NetworkInterface.c functions. I’m taking the “simple port” approach and will be leaving TCP enabled.

It would be great if you can share any successes you may have!

Here are my pack_struct_start.h and pack_struct_end.h files. No other edits required to resolve the #85 errors/warnings.

pack_struct_end.h (1.5 KB) pack_struct_start.h (1.6 KB)

I’m posting my current FreeRTOS+TCP v10.3.1 for TI Hercules RM57L project here.

IT IS NOT COMPLETED… currently, the FreeRTOS+TCP files are integrated and it will compile cleanly. In addition, I have started the updates to NetworkInterface.c that will be needed.

I’m following the porting guide here…

I’ve started mapping TI’s Halcogen generated HL_emac.c functions to FreeRTOS+TCP NetworkInterface.c functions (in the portable directory).

So far I have a prototype for xNetworkInterfaceInitialise() and am working on xNetworkInteraceOutput().

Any comments, help, contributions, etc. are welcome.
RM57L_FreeRTOS TCP_V10.3.1.zip (3.0 MB)

I’ve chosen to use BufferAllocation_2.c and pursue the “simple” interface as described in the porting guide.

Thanks for sharing this project! I had a look at your networkInterface.c and added some _HT_comments.

Here it is: NetworkInterface.HT.c (5.0 KB)

@htibosch THANKS!!! I’ll keep posting as I make progress. It’s slow going.

I’m still slowly making my way through the changes required for FreeRTOS+TCP. There has been a lot to absorb. I’m currently getting this set of undefined symbol errors:

MPU_xQueueCreateCountingSemaphore ./FreeRTOS-Plus-TCP/portable/BufferManagement/BufferAllocation_2.obj

MPU_xQueueReceive ./FreeRTOS-Plus-TCP/FreeRTOS_IP.obj

MPU_xQueueSemaphoreTake ./FreeRTOS-Plus-TCP/portable/BufferManagement/BufferAllocation_2.obj

MPU_xTaskGetCurrentTaskHandle ./FreeRTOS-Plus-TCP/FreeRTOS_IP.obj

I’m expect there is something simple I’ve forgotten to do but I don’t know what. Just a reminder… prior to addition of FreeRTOS+TCP files… I did have a FreeRTOS demo running on the RM57L with portUSING_MPU_WRAPPERS == 1.

Suggestions welcome.

I think the MPU prefix comes when you use the MPU protection wrappers. You need to make sure you have included source/portable/common/mpu_wrappers.c in your project.