W5500 에러 문의 건

[bluerock]

W5500이 기능적으로는 아주 잘 동작 하고 있습니다만… 에이징 테스트 중 아래의 두가지 에러가 발생했습니다…
전문가의 도움 부탁 드립니다.

참조 사항
기본 라이브러리 : IoLibrary V3.0.1
소켓 8개 사용 : 1개 Client, 7개 Listen
3일째 동작에서 아래의 에러가 발생

1. 첫번째 에러 : Socket.c의 send API에서 freesize가 항상 1로 무한루프에 빠짐

2. 두번째 에러 : socket.c 의 close api에서 SOCK_CLOSED 되지 않고 SOCK_ESTABLISHED (0X17) 로 계속 유지 되어 무한루프에 빠짐

감사합니다.

[Edward]

안녕하세요.

말씀하신 부분에 대해서 좀 더 명확한 설명 부탁드립니다.

1. 소켓 8개 중 7개는 Server(listen) , 1개는 Client(connect)로 설정한 뒤
   3일 째 어떠한 에이징 테스트를 하셨는지 명확한 설명 부탁드립니다.

2. 혹시 저희 W5500 칩만 사용해서 모듈을 제작하신건가요? 아니면 WIZ550io 같은 모듈을 구매해서 사용하신건가요?

3. 사용하신 코드는 어떤 코드를 사용하신건가요? 저희 예제코드를 사용하신건가요?? 예제코드를 사용하셨다면
   어떤 예제코드를 사용하셨나요?

추가 설명 부탁드립니다.

감사합니다.

[justinkim]

안녕하세요

에이징 테스트중 1~2일째까지 잘 되시다가 3일째 에러가 발생하셨다고 하셨는데요.

1번의 경우는 Window full 상태인것 같습니다. wireshark 같은 프로그램으로 패킷을 잡아보시면 확인 가능하구요
발생원인은 pc쪽 rx 버퍼가 가득차서 W5500 쪽 tx 버퍼에 있는 Data를 가져가지 못해 tx쪽 버퍼도 가득차게 되고
freesize가 1로 유지되어 발생하게됩니다.
이런 상황이라면 W5500에서 문제가 아니기 때문에 pc쪽 프로그램을 확인 해보시기 바랍니다.

2번의 경우에는 1번과 함께 발생한 에러인가요??
2번의 경우는 close api에 들어가서 멈추기 전에 close상태를 써주는데 그 커맨드가 안먹는 것 같은데 말이 안되는 상황이라 현재 주신 정보로는 파악이 어렵습니다.
해당 에러가 발생한 시나리오에 대한 정보를 더 자세히 설명해 주시기 바랍니다.

감사합니다.

[bluerock]

답변 감사합니다.

현상을 좀 더 상세히 설명 드리겠습니다.

== 하드웨어 정보 ==

1. W5500 칩을 사용하여 직접 하드웨어 제작 하였으며.
2. 2층에 1.6T PCB 기반 으로 제작 되었습니다. (첨부 PDF 참조)
3. 본 시스템은 LTE 라우터 밑에 12대가 W5500을 사용하여 TCP/IP로 묶여 있습니다.
4. 서버는 리눅스 서버로 KT 내부에 있습니다.
5. 본 시스템의 1차 버전은 필드에 4Set가 깔려 있습니다.
6. 현 시스템은 2차 버전으로 필드 출시를 기다리고 있습니다.
7. 1차 버전 역시 본 현상은 있으나, 워치독으로 리셋되면서 사용자는 알지 못하는 상황입니다.

== 소프트웨어 정보 ==

1. 위의 그림과 같이 본 시스템은 ip 기반으로 네트워크를 형성 합니다.
2. 개개의 노드는 직접 서버에 붙지 않고요… 메인 컨트롤러가 취합해서… 서버에 전송합니다.(서버 부하 감소용)
3. 소스는 귀사에서 제공하는 ioLibrary v3.0.1 기반으로 되어 있고요… loopback 기반으로 계속 체크 합니다.
4. 모든 노드는 STM32F429 + 8Mbyte SDRAM 코어 기반으로 송수신 Queue 사이즈는 2000개(600byte x 2000) 입니다.

== 디버깅 정보 ==

1. 총 12대 중 3대를 JTAG를 물려서 에이징 테스트를 하고 있었습니다.
2. 본 현상은 자주 나오지는 않구요… (운이 좋아서 3일째 발생)
3. 보통 일주일에서 한달에 한번 정도 나옵니다.
4. 그림의 freesize가 1인 노드는 메인 컨트롤러 이며, close가 안되는 것은 환경 노드 입니다.
5. 방어코드로 워치독을 넣어서 자동으로 원상 복구는 되지만… 원인을 알고 싶기도 합니다.
6. 1개의 Client는 부모에게 접속, 6개의 Listen은 자식이 붙는데 사용하며, 1개의 Listen은 log 분석용으로 사용
7. 즉, 메인 컨트롤러는 서버에 접속, 나머지는 부모 노드의 W5500에 붙습니다.
8. 개별 노드는 데이터 34바이트를 30초 간격으로 전송하다가…
9. 30분마다 카메라 이미지 (500바이트를 10ms 간격으로 평균 300개 정도) 보냅니다.
10. 즉, 메인 컨트롤러는 5개의 카메라노드로부터 30분마다 동시에 약1500개의 패킷(약 500byte)을 수신함
11. 추가적으로 모든 노드는 상호간은 네트워크 관리용으로 300byte정도의 정보가 30초 간격으로 상호 통신됨

== 의견 ==

1. justinkim님의 의견에서 pc쪽 rx가 full일 것이라는 의견은 아닌듯 한것이…
   서버의 다른 시스템은(동일 소프트웨어) 정상적으로 동작 하고 있으며…
   메인 컨트롤러를 리셋하면 정상적으로 동작합니다.
2. 또한 RX Queue와 TX Queue는 여유롭습니다.
3. 사실 본 글만 가지고 답변 주시기는 어려울 것이라고 판단됩니다.
4. 또한, 제가 제작한 PCB에 노이즈가 있을 수 도 있으니까요…
5. 혹, 이러한 현상이 있었으면 정보를 받고자 합니다.

== 추가 정보 ==

1. 자식 W5500이 부모 W5500에게 한번씩 커넥션이 끊어졌다가 재접속 합니다.(약 1,2시간 간격)
2. 부모가 서버인 메인 컨트롤러는 이러한 현상이 없었습니다.

== 추가 질문 ==

1. 위의 에러에서 W5500 하드웨어 리셋말고 내부 버퍼를 비우는 명령이 있을까요?
   W5500 하드웨어 리셋을 하면 ip 정보가 날아가서 시스템 로직이 좀 꼬여서요…
2. 프로토콜상 RSP가 오지 않으면 데이터는 버리지 않으니 W5500 내부 버퍼만 비울 수 있으면 데이터 로스 없이
   재전송이 가능 할 듯합니다만…

W5500_Module(1.0).pdf (489 KB)

[bangbh]

안녕하세요. 위즈네트의 방보현 연구원입니다.

비슷한 현상을 재현하기 위해 테스트 중이지만 시간이 너무 늘어지는 듯 하여 답글을 남깁니다.

1번 현상의 경우는 자신이 데이터를 내보낼 수 없거나 상대측이 데이터를 받을 수 없는 상태입니다.
비슷한 현상을 재현해 보자면 Establish가 되어 있는 상태에서 물리적 링크가 끊어지면 W5500은 Estblish 상태를 유지하게 됩니다.
이런 현상이 지속된다면 Buffer는 차오르게 되고 결국 while loop에서 나올 수 없게 됩니다. 하지만 TIME OUT에 의해 소켓은 자동으로 Close 됩니다.
이런 현상을 정확하게 분석하고자 한다면 wire shark등으로 data packet을 잡아 확인해야만 합니다.

2번 close 명령을 내렸음에도 close가 동작하지 않는 경우는 한가지 경우밖에 생각나지 않습니다.만약 OS를 사용하여 각기 다른 task가 같은 소켓에 접근하여 한 task는 close를 다른 한 task는 connect나 listen을 하게 된다면 close 동작 중 establish가 되는 현상이 생길 수도 있습니다. 혹시 OS를 사용하시는지 궁금합니다.

더 테스트를 해본 이후에 다시 답변드리도록 하겠습니다.

이상입니다.

[bluerock]

이렇게 적극적으로 대응해주셔 감사합니다.

저희 쪽에서도 계속 테스트는 진행 중에 있으며…
현재는 8개 socket의 loopback을 호출할때 각각의 loopback 사이에 delay를 1ms 를 주고 테스트 진행 중입니다만… 일주일이 넘게 동일 현상은 재연이 없습니다…
SPI clk 속도는 3M 밖에는 되지 않습니다만… W5500 내부 처리 속도보다 MCU의 처리 속도가 빠른가 하여서 테스트를 진행 하고 있습니다…

그리고, OS는 사용하지 않고 있으며, Blcoked 방식으로 단일 API에서 loopback을 호출하고 있습니다.

감사합니다.