First of all, I'm using RL-NET V4 Legacy, MDK 5.25. And the uC I am using is the ARM7 LPC2468.
The system I'm programming uses "a lot" of sockets. It has:- Default TCPNET HTTP server up to 3 sessions;- Default TCPNET FTP server 1 session;- A custom server for custom communications - up to 30 client TCPNET socket connections (Maintained by "Custom Comm" Task);- 1 TCPNET UDP socket for logging messages through the network to a specific logging app (logs from several tasks!);- 1 Default TCPNET DNS client.
And it has 2 BSD sockets:
- 1 BSD TCP socket for SQL querying (Maintained by "Database Querying" Task);- 1 BSD TCP socket for Internet communications / RESTful (Maintained by "Replication" Task);
All the TCPNET native sockets are used within the WebMain Task, and they are maintained through events/mailboxes shared between the WebMain Task and the other Tasks.In contrast with that, each BSD socket is used within each individual task, not in the WebMain Task.
The documentation just says that TCPNET NATIVE sockets must be dealt with in the Web Main Task, since it's functions are non-reentrant. Meanwhile, it says the BSD sockets support concurrency. It also says that BSD sockets are based on the TCP native sockets.
The reason I use both BSD and TCP native sockets is because in the beginning the development used only TCP native sockets, then we realised that for other new tasks it was easier to do by using BSD sockets.
But the question is, can I use both? Or I must stick with one of the them?
Memory functions are called internally from the TCPnet core, usually from TCP or UDP sockets. Therefore, it is important that the native socket functions are not called from different tasks.
Are you sure int_disable_eth() and int_enable_eth() are working properly?
Do you manipulate enabling / disabling EMAC interrupt from the interrupt handler? This can be dangerous because int_disable_eth() is usually not an atomic function.
Can you try the debug version and record MEM debugging messages? Maybe you can see there an indication of what would be wrong.
Hello Franc Urbanc
Thank you once again.
Franc Urbanc said:Are you sure int_disable_eth() and int_enable_eth() are working properly? Do you manipulate enabling / disabling EMAC interrupt from the interrupt handler? This can be dangerous because int_disable_eth() is usually not an atomic function.
It seems that the code is right. The Ethernet interrupt bit is the 21, as stated by the LPC24XX User Manual. See the code below.
Also, we don't manipulate enabling or disabling the ETH interrupt from any interrupt handler or other places.
/*--------------------------- int_enable_eth --------------------------------*/ void int_enable_eth (void) { /* Ethernet Interrupt Enable function. */ VICIntEnable |= 1 << 21; } /*--------------------------- int_disable_eth -------------------------------*/ void int_disable_eth (void) { /* Ethernet Interrupt Disable function. */ VICIntEnClr |= 1 << 21; }
Franc Urbanc said:Can you try the debug version and record MEM debugging messages? Maybe you can see there an indication of what would be wrong.
We will do this! Thank you!
#Edit:
We are doing the debugging with the debug version.For now we can tell that the int_disable_eth() function is working just fine, since if we comment the line:"VICIntEnClr |= 1 << 21;" we rapidly get the error: 698.4 MEM-ERR:Alloc, Recursive call
We will continue testing with the debug version to see if we get the ERR_MEM_LOCK.