BX3105 stops responding whenusing multiple sockets


#1

Hello,

for my application, I use my own webserver implementation (works find with other tcp/ip chips), since later we have not only the BX3105 as network interface and the webserver must use all network interfaces. Therefore, I cannot use the BX3105 internal HTTP host.

I have 3 problems with this:

  1. I cannot use Port 80 for my own purpose, even when not using the chips internal HTTP server.
  2. Whenever I try to access port 80 from a browser I get a login page with SSID and Password, even when I only use the station mode.
  3. My biggest problem: The BX3105 stops responding sometimes while I handle multiple sockets. My browser opens multiple connections to the module on Port 8080. I handle the HTTP request on each socket and afterwards the socket is closed. But it might happen that I get no response when closing a socket. I receive incoming connections and incoming data but no responses for my commands, as seen below. The Data with COM29 is sent, the Data with COM2 is received.

09:19:58.479 COM29> AT+KTCPSND=2,\0d\0a\09\09\09\09\3c\2fdiv\3e\0d\0a\09\09\09\3c\2fdiv\3e\0d\0a\09\09\3c\2fdiv\3e\0d\0a\09\3c\2fcenter\3e\0d\0a\3c\2fbody\3e\0d\0a\3c\2fhtml\3e\0d\0a
09:19:58.490 COM2>
09:19:58.490 COM2> OK
09:19:58.492 COM29> AT+KTCPCLOSE=2,1
09:19:58.594 COM2>
09:19:58.596 COM2> +KTCP_SRVREQ: 1,3,“192.168.178.54”,32753
09:19:58.596 COM2>
09:19:58.596 COM2> +KTCP_DATA: 3,331,GET /main.css HTTP/1.1
09:19:58.598 COM2> Host: 192.168.178.87:8080
09:19:58.600 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.600 COM2> Accept: text/css,/;q=0.1
09:19:58.600 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.602 COM2> Accept-Encoding: gzip, deflate
09:19:58.602 COM2> DNT: 1
09:19:58.602 COM2> Connection: keep-alive
09:19:58.602 COM2>
09:19:58.602 COM2>
09:19:58.622 COM2>
09:19:58.624 COM2> +KTCP_SRVREQ: 1,4,“192.168.178.54”,32756
09:19:58.624 COM2>
09:19:58.624 COM2> +KTCP_DATA: 4,315,GET /script.js HTTP/1.1
09:19:58.626 COM2> Host: 192.168.178.87:8080
09:19:58.628 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.628 COM2> Accept: /
09:19:58.628 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.630 COM2> Accept-Encoding: gzip, deflate
09:19:58.630 COM2> DNT: 1
09:19:58.630 COM2> Connection: keep-alive
09:19:58.630 COM2>
09:19:58.630 COM2>
09:19:58.851 COM2>
09:19:58.853 COM2> +KTCP_SRVREQ: 1,5,“192.168.178.54”,32757
09:19:58.853 COM2>
09:19:58.853 COM2> +KTCP_DATA: 5,315,GET /string.js HTTP/1.1
09:19:58.855 COM2> Host: 192.168.178.87:8080
09:19:58.857 COM2> User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
09:19:58.857 COM2> Accept: /
09:19:58.857 COM2> Accept-Language: de-DE,de;q=0.8,en-US;q=0.5,en;q=0.3
09:19:58.859 COM2> Accept-Encoding: gzip, deflate
09:19:58.859 COM2> DNT: 1
09:19:58.859 COM2> Connection: keep-alive
09:19:58.859 COM2>
09:19:58.859 COM2>
09:20:01.585 COM2>
09:20:01.586 COM2> +KTCP_SRVREQ: 1,6,“192.168.178.54”,32755
09:20:06.573 COM29> AT+KTCPCLOSE=2,1
09:20:07.581 COM2>
09:20:07.582 COM2> +KTCP_NOTIF: 6,4
09:20:12.577 COM29> AT+KTCPCLOSE=2,1

I hope someone can help me here.

EDIT: It seems to happen only when KTCPCLOSE is sent too early after KTCP_SEND. The at reference stated, that the system must be rebooted when KTCPCLOSE=session,1 is used on a server socket. Is this also the case for sockets that were gained from a server socket via +KTCPSERVREQ? If I wait manually for 100ms it does not happen often, like before.

My firmware revision is R1.3.0.201816011422.BX310x_1 with a bootloader version 1.0. A firmware update with firmware updater v2 to version 2.5.0 did not work. Since I did not find any full version change list, I do not know if this is an error, that is already fixed in later revisions.

Best regards,
Tim Koczwara


#2

@tikoesope,

You definitely need to use a newer version of firmware (there are a huge number of improvements in the later versions such as 2.5), given you are on version 1.3 then it is pretty certain that you unit is not able to be upgraded as it is too old (digital signature of the firmware changed mid way through the development process).

Only way to resolve this is to get your hands on a newer unit.

Regards

Matt


#3

Hi Matt,

thanks for the response. I feared that this would be the case.
I try to get modules with a newer firmware. I hope my distributor does not only have old firmware modules.
Is there a way to identify “old chips” before mounting them on boards?

Best regards,
Tim Koczwara


#4

@tikoesope

There should not be any older units in the system anymore old units in the field any more as it was quite a while ago this happened.

Regards

Matt