2017-09-22 8 views
0

이것은 WinUsb 드라이버와 라이브러리를 사용하는 첫 번째 프로젝트입니다.WinUsb : OUT 파이프에 쓰면 IN 파이프에서 데이터가 손상됩니다.

내 호스트 컴퓨터는 WINDOWS 10을 작동하며 모든 업데이트가 설치되어 있습니다. 내 고속 장치가 세 개의 데이터 종점을 작동합니다. - OUT 명령 종단점 : 호스트 컴퓨터가 명령을 보내기 위해 호스트 컴퓨터를 사용합니다. - IN 응답 종점 : 호스트 컴퓨터가 각 명령에 대한 응답을 수신합니다. - IN 스트림 종단점 : 기간이 10 밀리 초인 1600 바이트 호스트 응용 프로그램에서

, 두 개의 관련 스레드가 : - 명령 스레드가 파이프를 명령하는 명령을 전송하고 회신 파이프에서 응답을 수신 - 스트림 스레드는 스트림 파이프 비 대기 기능의 데이터는 모든 파이프에 사용되는 수집 .

다른 스레드가 일시 중단되면 각 스레드가 완벽하게 작동합니다. 그러나 두 스레드가 동시에 작동하면 스트림 데이터가 임의의 지점에서 손상된 것처럼 보입니다.

자세한 분석은 다음과 같은 사실을 밝혀 : 는 - 부패가 잘못된 바이트의 연속 순서로 나타납니다. 잘못된 시퀀스의 길이는 대략 명령 및 응답 길이에 해당합니다. - 패킷 경계와 관련이없는 임의의 지점에서 잘못된 시퀀스가 ​​시작됩니다. - 잘못된 바이트가 다를 수 있습니다. 때로는 모두 0이므로 가끔 쓰레기로 보입니다. - 시간 분석은 명령이 명령 파이프로 보내지면 손상이 발생했음을 나타냅니다.

은 스레드 간 동기화를 구현하면이 사라 지므로 읽기/쓰기 작업이 시간적으로 분리됩니다. 그러나 이것은 받아 들일 수없는 해결책입니다. 두 개의 스레드가 비동기 적으로 작동하기를 바랍니다. 아무도 그러한 효과에 직면 했습니까? 내 자신의 질문에 대답

+0

라이브러리를 의심 할만한 이유가별로 없으며, 특히 얼마나 자주 봤는지, 얼마나 적은지를 감안할 때 그렇습니다. 훨씬 더 가능성이 장치 펌웨어에서 잘못 될 것입니다. 무슨 일을하는지. –

+0

장치 펌웨어는 내 프로젝트의 일부이기 때문에 처음으로 추측했습니다. 따라서 전송 전후에 스트림 버퍼 무결성 검사를 구현했습니다. 문제는 발견되지 않았습니다. –

+0

라이브러리 나 펌웨어가 아닌 경우 하드웨어 만 남아 있습니까? –

답변

0

...

한스 '의견은 정확했다가, 문제는 펌웨어에 뿌리를두고 있었다. 내가 같이가 Atmel의 코어 텍스 M7 시리즈를 사용하는 경우 특히

더 자세한 사항은, 장치 펌웨어 개발자를위한 흥미로운 일이 될 수 있습니다.

이 시리즈에서 USB 컨트롤러에는 끝점 버퍼링을위한 듀얼 포트 RAM이 포함되어 있습니다. DPRAM은 하드웨어에 의해서만 할당되고 관리됩니다. 펌웨어는 엔드 포인트 제어 레지스터의 ALLOC 비트를 설정하여 할당을 초기화합니다. 사용자 매뉴얼에서 펌웨어는 ALLOC 비트를 오름차순으로 설정해야합니다. 일단 프로젝트 히스토리에서,이 변경이 DPRAM 할당의 오름차순을 위반한다는 사실을 깨닫지 못하면 엔드 포인트 디스크립터에서 엔드 포인트 주소를 변경했습니다. 결과적으로 엔드 포인트 버퍼가 중첩되어 나타나서 질문에 설명 된 데이터 간섭이 발생했습니다.

버그를 수정 한 후에도 문제가 없습니다.