A few question regarding the timeout parameter for m2m_socket_bsd_select().
1.) Specifiying a NULL pointer like “m2m_socket_bsd_select(1, &readfds, NULL, NULL, NULL);” leads to crash. According to the documentation it should be possible to specify a null pointer, no?
2.) Even so a timeout is specified m2m_socket_bsd_select() appears to return straight away with 0 for me (indicating a timeout). Here’s what I do:
rc = m2m_socket_bsd_select(1, &readfds, NULL, NULL, &bsd_start); I would expet this to wait for 10 seconds but it reurns straight away with 0. Any idea where I’m going wrong.
3.) Whenever my appzone application crashes the module seems to crash as well and I have to restart it manually. Is there a way to prevent this?
I’m working with the LE910 v2.
Thanks,
Peter
Hello,
it should not exit nor should it crash. Can you provide me the whole source code so that I can compile and run it?
Also, when AppZone crashes the module crashes too but it should reboot automatically
BR
Moreno
Hello Moreno,
I found what was wrong with the m2m_socket_bsd_select() timeout – I suspect the API documentation. It states that:
“Parameters:
nfds: number of sockets on which information is required; …”
I think this is incorrect. It should be like the normal BSD select which states “nfds should be set to the highest-numbered file descriptor in any of the three sets, plus 1.”
So for me a m2m_socket_bsd_select(fd + 1, &readfds, NULL, NULL, &bsd_timeout); instead of m2m_socket_bsd_select(1, &readfds, NULL, NULL, &bsd_timeout); appears to fix the issue.
Could you check if the API documentation is maybe incorrect there?
But a m2m_socket_bsd_select(fd + 1, &readfds, NULL, NULL, NULL) still leads to a crash.
Also, occassionally the module only shuts down but doesn’t restart after a ‘AT+M2M=4,10’. Any ideas why that might be?
Also, after a crash I sometimes see a new USB comm port appearing labelled ‘Core Dump’. Any information on how to use this port? It seems to provide some sort of massive core dump.
Apologies for too many questions in one go.
Thanks,
Peter
Ok I see what’s the issue.
You shouldn’t normally be able to see the core dump port. If your module is configured for core dump, it doesn’t reboot con crash but it waits for you to connect con the core dump port.
If you don’t need this debug configuration you should flash a regular firmware instead of the debug one and if that isn’t enough I’ll guide you through the AT commands to disable core dump.
I’ll look into the socket descriptor issue, it will take me some time to reproduce the issue, test the same code on different platforms and eventually open a bug.
It would speed up things a lot if you could strip your code to leave only the crash part and send it to me
BR
Moreno
Hi Moreno,
Yes, I had indeed a beta image. I upgraded to the latest version yesterday and it seems to behave better.
Would you know where I can get the schematics for the LE910 EU v2 EVK daughter card? I want to evalute the use of the GPIOs next.
And don’t worry too much about the crash. But here’s the code that should reproduce it:
struct addrinfo { int ai_flags; int ai_family; int ai_socktype; int ai_protocol; socklen_t ai_addrlen; M2M_SOCKET_BSD_SOCKADDR *ai_addr; char *ai_canonname; struct addrinfo *ai_next; };
We use cookies to enhance your browsing experience and help us improve our websites. To improve our website, we carefully select third parties that use cookies to allow us to serve specific content and achieve the purposes set out in our cookie policy. For more information on how to make adjustments through your browser to the cookies being used on your device, please click Find Out More link. By closing this banner or continuing to browse our website, you agree to our use of such cookies. FIND OUT MORE
Hi,
A few question regarding the timeout parameter for m2m_socket_bsd_select().
1.) Specifiying a NULL pointer like “m2m_socket_bsd_select(1, &readfds, NULL, NULL, NULL);” leads to crash. According to the documentation it should be possible to specify a null pointer, no?
2.) Even so a timeout is specified m2m_socket_bsd_select() appears to return straight away with 0 for me (indicating a timeout). Here’s what I do:
M2M_SOCKET_BSD_FD_SET readfds;
M2M_SOCKET_BSD_TIMEVAL bsd_start;
…
bsd_start.m_tv_sec = 10;
bsd_start.m_tv_usec = 0;
m2m_socket_bsd_fd_zero_func(&readfds);
m2m_socket_bsd_fd_set_func(fd, &readfds);
rc = m2m_socket_bsd_select(1, &readfds, NULL, NULL, &bsd_start);
I would expet this to wait for 10 seconds but it reurns straight away with 0. Any idea where I’m going wrong.
3.) Whenever my appzone application crashes the module seems to crash as well and I have to restart it manually. Is there a way to prevent this?
I’m working with the LE910 v2.
Thanks,
Peter
Hello,
it should not exit nor should it crash. Can you provide me the whole source code so that I can compile and run it?
Also, when AppZone crashes the module crashes too but it should reboot automatically
BR
Moreno
Hello Moreno,
I found what was wrong with the m2m_socket_bsd_select() timeout – I suspect the API documentation. It states that:
“Parameters:
nfds: number of sockets on which information is required;
…”
I think this is incorrect. It should be like the normal BSD select which states
“nfds should be set to the highest-numbered file descriptor in any of the three sets, plus 1.”
So for me a
m2m_socket_bsd_select(fd + 1, &readfds, NULL, NULL, &bsd_timeout);
instead of
m2m_socket_bsd_select(1, &readfds, NULL, NULL, &bsd_timeout);
appears to fix the issue.
Could you check if the API documentation is maybe incorrect there?
But a m2m_socket_bsd_select(fd + 1, &readfds, NULL, NULL, NULL) still leads to a crash.
Also, occassionally the module only shuts down but doesn’t restart after a ‘AT+M2M=4,10’. Any ideas why that might be?
Also, after a crash I sometimes see a new USB comm port appearing labelled ‘Core Dump’. Any information on how to use this port? It seems to provide some sort of massive core dump.
Apologies for too many questions in one go.
Thanks,
Peter
Ok I see what’s the issue.
You shouldn’t normally be able to see the core dump port. If your module is configured for core dump, it doesn’t reboot con crash but it waits for you to connect con the core dump port.
If you don’t need this debug configuration you should flash a regular firmware instead of the debug one and if that isn’t enough I’ll guide you through the AT commands to disable core dump.
I’ll look into the socket descriptor issue, it will take me some time to reproduce the issue, test the same code on different platforms and eventually open a bug.
It would speed up things a lot if you could strip your code to leave only the crash part and send it to me
BR
Moreno
Hi Moreno,
Yes, I had indeed a beta image. I upgraded to the latest version yesterday and it seems to behave better.
Would you know where I can get the schematics for the LE910 EU v2 EVK daughter card? I want to evalute the use of the GPIOs next.
And don’t worry too much about the crash. But here’s the code that should reproduce it:
struct addrinfo {
int ai_flags;
int ai_family;
int ai_socktype;
int ai_protocol;
socklen_t ai_addrlen;
M2M_SOCKET_BSD_SOCKADDR *ai_addr;
char *ai_canonname;
struct addrinfo *ai_next;
};
…
M2M_SOCKET_BSD_SOCKET fd;
UINT32 block_mode;
struct addrinfo *server = m2m_os_mem_alloc(sizeof(struct addrinfo));
M2M_SOCKET_BSD_SOCKADDR_IN *addr = m2m_os_mem_alloc(sizeof(M2M_SOCKET_BSD_SOCKADDR_IN));
addr->sin_addr.s_addr = m2m_socket_bsd_inet_addr(“1.2.3.4”);
addr->sin_port = m2m_socket_bsd_htons(4711);
addr->sin_family = M2M_SOCKET_BSD_PF_INET;
server->ai_family = M2M_SOCKET_BSD_AF_INET;
server->ai_socktype = M2M_SOCKET_BSD_SOCK_STREAM;
server->ai_protocol = M2M_SOCKET_BSD_IPPROTO_TCP;
server->ai_addr = (M2M_SOCKET_BSD_SOCKADDR *)addr;
fd=m2m_socket_bsd_socket(server->ai_family, server->ai_socktype, server->ai_protocol);
m2m_socket_bsd_connect(fd, server->ai_addr, server->ai_addrlen);
block_mode = 0;
m2m_socket_bsd_ioctl(fd, M2M_SOCKET_BSD_FIONBIO, &block_mode);
m2m_socket_bsd_fd_zero_func(&readfds);
m2m_socket_bsd_fd_set_func(fd, &readfds);
m2m_socket_bsd_select(fd + 1, &readfds, NULL, NULL, NULL);
Thanks,
Peter
I see you opened a different thread for the EVK2 schematics, I’ll answer you there
Hello Peter,
it’s not clear to me wheter you solved this issue yourself or not. Shall I investigate the crash regarding the sockets?
Best regards
Moreno