AM2434: am2434

Hi Baruch Einziger,

Thanks for your query.

Can you please provide some more details ?

Regards

Ashwani

hi Goel

i bind my socket to my static ip and it's work till i change my port number in my python UDP server.

this is the code i add to the UDP client example:

struct sockaddr_in local_addr; // 10042025

local_addr.sin_family = AF_INET;
local_addr.sin_port = htons(0);
local_addr.sin_addr.s_addr = inet_addr("192.168.1.200"); // my static IP 

if (lwip_bind(sock, (struct sockaddr*)&local_addr, sizeof(local_addr)) < 0) {
printf("bind failed\n");
while (1);
}

I would appreciate your guidance on the following issue:

How can I configure lwIP to work with UDP using a single IP address across multiple ports, with a clear separation between receive and transmit operations?

That’s the core of my question. Thank you in advance for your support.

Best regards,
baruch

Hi baruch,

If you assume that binding socket to 0 would receive from any port number, that wont work. 0 is a reserved port number.

Do you want to open a single socket and receive any UDP packet which just matches the IP address and regardless of the port number?

Baruch Einziger said:

, with a clear separation between receive and transmit operations?

Can you please elaborate on this? 

Regards,

Thilak

hi Thilak Karanam

That's exactly what I was trying to do.

thanks 

Baruch

Hi Baruch,

The concept of Socket is based on the touple of IP address and port number. But unlike broadcast MAC address and IP address, we don't have support for broadcast port number. To listen to a traffic from an IP address, it should listen on a given port number as long as the application is acting like a client.

The idea of a single socket receiving packets from all port numbers from a given IP on client side looks like an unconventional method. Can you please help me understand the usecase more so that we can check for alternative approaches?

Regards,

Teja.

Hi Teja

When working with UDP on a single Ethernet IP address, I am currently limited to receiving only one message at a time. Ideally, if I could capture messages from all ports simultaneously, I could efficiently filter and manage them through software. The existing solution, which requires creating a separate thread for each port, is too resource-intensive for my AM243x LP card.

I attempted to use PCB to handle input reception via callback routines, but unfortunately, I have not yet succeeded. The reason for this issue remains unclear. I've raised this problem in the E2E forum but have not received any helpful responses so far.

best regarde

baruch

Hi Baruch,

Following the meeting, I understood that you need to receive UDP traffic for given IP address and pass the subsequent data based on the port to multiple cores, over shared memory. I would suggest that this would be better equiped if each of the core has unique IP if the number of processes going to run on each core has to be scalable. You can take a look at an example which demonstrates similar capabilities here: https://software-dl.ti.com/mcu-plus-sdk/esd/AM64X/latest/exports/docs/api_guide_am64x/EXAMPLES_ENET_INTERCORE_ICSSG.html

Or, you can increase the task size as you are making use of more threads running in parallel. You can increase the stack size availablke for freertos in the following location. Please look for MAIN_TASK_SIZE: source/networking/enet/core/examples/lwip/enet_cpsw_udpclient/am243x-lp/r5fss0-0_freertos/main.c

Meanwhile, Let me evaluate other options that you can use without having much overhead per new port being added.

Regards,
Teja.

Dear Teja,

I cannot accept the idea of running two instances of lwIP and FreeRTOS, as I am severely constrained by memory limitations in my current working environment with the AM243X-LP.

To manage my memory constraints effectively, I have configured my application to use only core R00 for handling UDP communications on four ports with a single IP address. Your suggestion involves using two IP addresses and only one port, which unfortunately does not align with my requirements.

R01 to handle the UART interface.

The primary issue I am encountering is that after adding additional code to my thread, it aborts on subsequent system calls, such as lwip_recvfrom (which only executes successfully once), IpcNotify_sendMsg, or SemaphoreP_post. When I attempt to debug, the thread crashes immediately upon re-entering the loop or upon reaching a breakpoint set at the lwip_recvfrom call.

I have tried increasing MAIN_TASK_SIZE, but this introduced additional issues, and I am currently investigating them further.

Could you please advise me on how best to proceed?

Thank you,

Baruch

increasing MAIN_TASK_SIZE change and reducing the DEFAULT_THREAD_STACKSIZE to 3K solve my problem with 4 threads now i will try to active 5 threads and 5 sockets

thanks

Baruch. 

Hi Baruch,

This is a configuration that is set in the LwIP library. By default, we support 4 parallel active connections. You can increase this limit by adjusting the parameter 'MEMP_NUM_UDP_PCB' in lwipopts.h file. You can find this file at <($MCU_PLUS_SDK)/source/networking/lwip/lwip-config/am243x/lwipopts.h>

/* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One
   per active UDP "connection". */
#define MEMP_NUM_UDP_PCB        4 // Increase this to the required number

By increasing this number to your desired number, you can open more than 4 sockets at a time, which is the default value

Regards,
Teja.

Hi Tega,

I tried both suggested changes, but I’m still unable to declare more sockets. I'm attaching the modifications I made for your review.

Below are the relevant sections from my lwipopts.h:

And from the beginning of my main.c:

Despite these changes, the software returns an error when I attempt to create the 5th socket.

Best regards,
Baruch

Hi Baruch,

Ideally, the changes you have made should resolve the issue. Let me try to recreate this on our setup. Since I am on another commitment now, I will give you an update by EoD 12th May.

Thanks and regards,
Teja.

Hi Baruch,

I have tested the application opening more than 4 parallel connections with UDP. Apart from increasing MEMP_NUM_UDP_PCB to 6, I had to increase the heap size to accommodate for the additional dynamic memory requirements. You can increase the FreeRTOS stack and heap sizes from the syscfg-gui tool. Please look for Memory Configurator>General>Stack Size and Heap Size. Please update the stack and heap sizes, recompile the Libraries and example.

If you face any other issues, please let us know.

Regards,
Teja.

Hi Baruch,

Is it the case that there is no free memory available in the system from MSRAM? If yes, then it will be a better call to wait till you can work on boards with DDR since I have already verified the feasibility of opening more than 5 sockets at a time.

But I still suggest you to consider if assigning unique IP to each core is feasible since that is a much better option for scalability with lesser memory impact. Drivers to route ethernet traffic via shared memory between cores is already available as part of MCU+ SDK, but you have to enable it for AM243x since the example is not supported out of box.

Regards,
Teja.

Hi Teja,

I have an important milestone coming up next month. Currently, I'm working with one IP address managing more than five sockets, although I'm currently utilizing four. Ethernet handling is managed by core R00, and I am efficiently utilizing shared memory (part of MSRAM) for all Ethernet UDP buffers without additional copying.

I'm employing IP Notify to transmit 28 bits of data, which include buffer indices stored 8. bits each.  in shared, non-cacheable memory, along with an additional 12 bits dedicated to parameters. Meanwhile, core R01 manages UART communications, each with a dedicated 64-byte buffer supporting data rates up to 3 Mbps, and the response time has been excellent.

I'm now preparing to demonstrate the capabilities of the AM2434 to my client. I'm optimistic about securing a significant project, which would enable me to design my own hardware solution incorporating DDR4 memory. So far, my shared memory strategy and IPC notify messaging concepts have proven highly effective.

Best regards, 

Baruch

Hi Baruch,

Baruch Einziger said:

I'm now preparing to demonstrate the capabilities of the AM2434 to my client. I'm optimistic about securing a significant project, which would enable me to design my own hardware solution incorporating DDR4 memory. So far, my shared memory strategy and IPC notify messaging concepts have proven highly effective.

Thanks for the update, and I hope there are no more issues that you are facing for the demonstration. Please let me know if you face any.

Thanks and regards,
Teja.