Invalid socket status for socket operation

W7500 Loopback(TCP Server)예제를 토대로 6ms마다 Client(PC)로 12bytes 데이터를 보냅니다.

W7500(Server)–>Client로 패킷 전송

Client는 단순히 데이터를 받기만 합니다.

정상적으로 작동되다가 5분~1일 간격(랜덤)으로 Send()함수에서
#define SOCKERR_SOCKSTATUS (SOCK_ERROR - 7) ///< Invalid socket status for socket operation.
이 값을 리턴하고 접속이 끊깁니다.

정상 작동중에 위와같은 값이 호출되는 이유를 알수있을까요?
Client에서는 데이터 패킷을 받고나서 정상적으로 ACK를 보냅니다.

SOCKERR_SOCKSTATUS를 return 할 경우는 send 함수내용을 보면 알 수 있습니다.

getSn_SR로 상태를 읽어왔는데 ESTABLISHED와 CLOSE_WAIT 상태가 모두 아닐경우 ERR를 리턴합니다.
현재 Sn_SR 상태값을 읽어 보시기 바랍니다.

client 쪽에서 ack가 늦게와서 timeout이 나는 것은 아닌지요?

firmware와 패킷을 다시한번 확인 해보시기바랍니다.

그리고 이어지는 질문은 하나의 게시물로 reply 부탁드립니다.

  1. Send함수 직전에 항상 Sn_SR상태값을 한번 더 읽어온 결과, ESTABLISHED상태입니다.
  2. PACKET확인 결과, Client에서는 ACK를 항상 10ms이내에 보냅니다.
  3. 첨부그림은 마지막 Send함수에서 SOCKERR_SOCKSTATUS를 리턴하기 바로 직전까지의 패킷입니다.
    정상적으로 서버와 클라이언트가 통신이 이뤄지고, 뜬금없이 Send에서 SOCKERR_SOCKSTATUS를 리턴합니다.

혹시,
getSn_TX_FSR()
getSn_SR()
wiz_send_data() 와 같은 함수들 중간에 인터럽트(UART Recv, Timer)가 걸리면 예상치 못한 오류가 발생하나요?

현재 Send()함수를 Main에서 돌아가고있고, Uart, Timer 인터럽트 사용중입니다.


저도 잘 이해가안되네요

W7500이 server라고 하셨는데 최초의 패킷은 client가 보내는것인가요?

동작과정을 다시 설명해주시면 감사하겠습니다

같은방법으로 test 해보려고 합니다.

괜찮으시면 올리신 firmware를 justinkim@wiznet.io로 보내주시면 그걸로 test해보겠습니다.

동작과정

  1. UART0을 통해서 W7500이 실시간으로 외부에서 스트림 데이터를 받습니다.
  2. W7500이 UART0에서 받은 데이터를 검사 후, 12bytes씩 나눠서 1Packet을 만듭니다.(1packet 만들어지는데 약 6ms)
  3. TCP socket(총4)중 ESTABLISHED된 소켓으로 패킷을 전송합니다.(W7500이 SERVER입니다.)

혹시 send()함수 실행중에, 다른 인터럽트가 발생하면 문제가 발생할 확률이 있나요?

그외의 문제 발생원인들이 없는것으로 보여서, 질문드립니다…

클라이언트는 w7500에 접속만 하고 특별한 일이 없는 한, 서버에서 주로 데이터를 보냅니다.

메일로 펌웨어 보냅니다.

Send()함수 호출전에 getSn_TX_FSR()로 내부 버퍼 가용 공간 확인결과,
평상시엔 0x800(2048)로 보내면 바로바로 돌아갑니다.
그러다가 어느순간 버퍼 메모리가 처리가 안되고, 계속 쌓여서 메모리 공간이 줄어듭니다.
클라이언트에서는 정상적으로 ack를 보내는데 버퍼에 메모리가 쌓이는 다른 원인이 있나요?

server부문만 참고하여 현재 server에서 60ms마다 client로 data 보내는 test 중입니다.
1시간이 지났지만 아직까지 연결이 끊어지지않습니다.
최초에 client 쪽에서는 connect만 하나요?? 종료시에 client에서 rst packet을 보낸다지 하지 않나요??
getSn_SR()함수에서 1~3초가 머문다고 하셨는데 그 상황에 interrup가 발생하여 3초간 다른 일을 하지 않는다면 그럴일이 없을 것 같습니다.
만약 timeout으로 close가 되는 상황이라면 RTR 값을 조정하여 timeout 시간을 늘리면 될 텐데 현재 상황으로 봐서는 RST 패킷을 받아 connection이 끊어지는 것으로 보여집니다.