Lime core is the networking processor which was found to be present in DIGIC 7 and above. The main motive behind this was to ease debugging by using a network-based debugger Scout which can possibly run on the camera.

All the investigations below were done under 200D (SL2) at version 1.0.1.

ESP32

The networking processor was found to have a DryOS implementation with an interactive shell which can be accessed from the ICU through UART. Now before accessing it, the Lime core needs to be powered on. This can simply be done from the Canon GUI where the WIFI can be enabled (WPS led blinking). Interestingly enough a new category is added to the ICU dry shell help command(?) named NetDomain when the networking processor is on.

[NetDomain]
 netlog

running netlog in the dry shell printed the following:

NETLOG(   18):    7.55sec(0x02f3) [PComNetCommonIF.c:443] leave_drv
NETLOG(   34):    7.55sec(0x02f3) [PComNetCommonIF.c:466] enter_drv
NETLOG(   50):    7.55sec(0x02f3) [PComNetCommonIF.c:473] leave_drv
NETLOG(   66):    7.55sec(0x02f3) [PComNetCommonIF.c:466] enter_drv
NETLOG(   82):    7.55sec(0x02f3) [PComNetCommonIF.c:473] leave_drv
NETLOG(   98):    7.55sec(0x02f3) [PComNetCommonIF.c:466] enter_drv
...

This log most likely showed the interactions from the ICU to the Lime core on the lower level as it was filled with leave_drv and enter_drv messages and nothing more.

Now from the dry shell(ICU), executing uart_change when LIME was active changed the shell from Dry[MusaPUX]> to Dry[LIME]>.

The help command ? printed the following:

Dry[MusaPUX]> uart_change
Dry[LIME]> ?
[Kern]
 extask  meminfo  mkcfg  dminfo  exobjinfo  stdlibcfg  sysvers  xd  xm  prio
 resume  suspend  release  sem  mutex  event  mq
[User]
 exit  timer  mkobjsize  kill  delete  cmp  date
[Test]
 time  count  mktest  iotest  chkspi
[Network]
 netvers  eci  arp  dhcpc  ifconfig  mbufs  netstat  route  ping  tcputil
 dnsutil
[WELL]
 nell-attach  nell-detach  nell-wakeup  nlog  up  down  stat  scan  join
 leave  wset  wget  wep  w12get  w12set  elog  uap  wfd
[TMN]
 tm  rt  wpse  wpscmd  wcf  wcfcmd
[Utility]
 uart_change
[NetDomain]
 wprd  wtst  actlog

PComNetSocket is the 'api' which transfers commands from the ICU to Lime and vice versa.

Every registered function which can be called from the ICU to Lime has the prefix of Invoke in Lime.

Approximately 53 functions can be 'invoked' the from ICU from the PComNetSocket API for the CommonSyncWrite table.

There are multiple tables but CommonSyncWrite is the most useful one since it exposes some of the higher level sockets.

Every function which can be called is on a table at 0x01a9f9a5(CommonSyncWrite) and the first one being InvokeSocket.

(Was found using a string search of Invoke)

function FUN_E07146B8 takes in three parameters which apparently lookup the table on the Lime core, processes the function on the Lime core and returns the result back to the ICU.

FUN_E07146B8(int index,int *parameterArray,int parameterArraySize)

Canon already has many 'filler' functions for Lime functions which should be called instead and they can be found by looking up the xrefs of 0xe07146b8 with the parameters passed in.

For example socket_bind which is InvokeBindConnectCommon with an index of 2 is passed to 0xe07146b8 like this:

 FUN_E07146B8(0x2,&local_28,0x14); 

In this case, local_28 would hold the return values as this function is also blocking.

Here are the common networking stubs found:

socket_select_caller is not the actual socket_select function since this function needs the descriptors to be converted by the socket_convertfd function and the fd_set used must also be converted by socket_convertfd.

So socket_select could look like this:

 
int socket_select(int sockfd, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)
{
    int converted = socket_convertfd(sockfd);
    return socket_select_caller(converted, readfds, writefds, exceptfds, timeout);
}

and the fd_set could look like this:

typedef struct my_fd_set
{
    uint32_t fds_bits[64];
} my_fd_set;

int my_FD_ISSET(unsigned long n, struct my_fd_set *p)
{
    int convert = socket_convertfd(n);
    uint32_t mask = 1 << (convert % 32);
    return p->fds_bits[convert / 32] & mask;
}

void my_FD_SET(unsigned long n, struct my_fd_set *p)
{
    int convert = socket_convertfd(n);
    uint32_t mask = 1 << (convert % 32);
    p->fds_bits[convert / 32] |= mask;
}
void my_FD_CLR(unsigned long n, struct my_fd_set *p)
{
    int convert = socket_convertfd(n);
    uint32_t mask = 1 << (convert % 32);
    p->fds_bits[convert / 32] &= ~mask;
}

socket_bind and socket_connect takes in three parameters. The array which is passed in should look like this:

char sockaddr[8];

// 1 = IPv4, 2 = IPv6, 3 = Ethernet
sockaddr[0] = 0x00;
sockaddr[1] = 0x01;

// port 25565
sockaddr[2] = 0x63; // low byte
sockaddr[3] = 0xdd; // high byte

// ip address: 192.168.10.22
sockaddr[4] = 192;
sockaddr[5] = 168;
sockaddr[6] = 10;
sockaddr[7] = 22;

socket_bind(sock,sockaddr, 0x8)
socket_connect(sock,sockaddr, 0x8)