usocket and uselect reboots board

OpenMV Products
#1

Hi guys

Im doing a project where im using tcp sockets on the openMV - that actually works quite well but the usocket.recv() is a blocking operation.
Following general suggestions online in how to do non blocking tcp in python i found the “select” session - and found the uselect library in openMVs micropython - i was happy! but!

Everytime i do anything regarding uselect and usockets the openmv board simply reboots … doesnt even matter HOW simple a piece of code i write :frowning: is this a known bug/thing?
Or am i missing something?

Like even doing a poll with socketEvent = poller.poll(100) resets the board - no matter the length of the timeout

#2

Can you post a test script ? We can debug and fix it then.

#3

hmm, doesnt seem im allowed to write the script here - i tried commenting with it - but i keep getting an error about “/posting.php”
But anyways - the code ive attached is just a test script that connects to a wifi then to a tcp server (i wrote one in nodejs - but any tcp server should do)
as soon as the line

fdVsEvents = pollObj.poll(1000)

is run - the board reboots - ive tried this with two separate openMV boards both running firmware 3.2.0

hope it helps :wink:
tcp-select-test-forum.py (938 Bytes)

#4

I should probably note that any function in the uselect library ive tried reboot the board -

uselect.select

for instance also reboots

#5

Okay I see the problem, actually we don’t implement select/poll in the WINC1500 driver. The ioctl function is not even set (it shouldn’t crash the cam however, I’ll debug this). You can’t use this module for now, but you can use the set timeout function to zero instead to set the socket to non-blocking (it’s basically the same effect).

#6

i cant for the life of me make this nonblocking - neither settimeout or setblocking commands are doing anything
the openmv cam is the client and server is written in nodejs, do i need something on the server side to fix this?

#7

Hi, settimeout works, in the tcp_client.py example if you set the timeout to 0.01 (10ms) you will get an exception.

#8

i might have misunderstood something basic about tcp sockets :slight_smile:
i got the timeout to work but now i get access denied when attempting to read from the socket again
do i need to open the connection again to keep reading from the socket? the funny thing is that if i disable the timeout i can keep communicating via the socket
but the program will hang until it gets data from the server

#9

okay, so the plot kind of thickens
I rewrote my code to use MQTT - whenever i use

client.check_msg()

the code hangs like when im doing my own TCP stuff - it seems that something is broken in the way OpenMV handles tcp sockets …
as far as i can tell the mqtt check_msg function should return immediately if there is no message pending from the server - but it doesn’t

#10

again - further madness here (i think - i might be wrong)
if i do a

client.ping()

before doing

client.check_msg()

the code behaves as expected

#11

okay - so my thinking is that the ping → response cycle is returning something that makes the

socket.recv()

function do it’s thing and allowing the code to progress while still accepting actual messages from the server with data in it - im still pretty new at the whole python and networking thing so this might be wrong or actually the right way to do it - i don’t know - but basically its working as intended now - thx for your help btw :wink:

#12

Hi, just wanted to let you know that there were bugs in the WINC1500 driver wrapper, specifically the way timeouts were handled, which affected recv/recvfrom on non-blocking sockets, and check_msg in turn. These bugs are fixed now, setblocking(True/False) should work as expected and you shouldn’t need to call ping before check_msg(). I’ve also added another MQTT example showing how to subscribe to a topic. Thanks for bringing this to my attention.

Note: There fixes will be available in the next release.