1

This is my first project using WinUsb driver and library.

My Host computer operates WINDOWS 10, all updates installed.
My High Speed device operates three data endpoints:

  • OUT Command endpoint: the Host computer uses it to send command
  • IN Reply endpoint: the Host computer receives reply to each command
  • IN Stream endpoint: the device sends stream data, 1600 bytes with period 10 milliseconds.

In the Host application, there are two relevant threads:

  • Command thread sends commands to Command pipe and receives replies from Reply pipe
  • Stream thread collects data from Stream pipe

Non-waiting functions are used for all pipes.

Each thread works perfect if another thread is suspended.
However, if two threads work concurrently, the stream data appears corrupted in arbitrary points.

More analysis revealed the following facts:

  • Corruption appears as a contiguous sequence of wrong bytes. The length of wrong sequence roughly corresponds to the length of commands and replies.
  • Wrong sequence starts from arbitrary point not related to packet bounds.
  • Wrong bytes may be different; sometimes, they are all zeroes, sometimes they looks as garbage.
  • Time analysis suggests that the corruption occurs once the command is sent to Command pipe.

The effect disappears if I implement synchronization between the threads, so that read/write operations are separated in time. However, this is not acceptable solution, I want two threads to work asynchronously.
Has anybody faced such effect?

GSerg
  • 76,472
  • 17
  • 159
  • 346
S.Chrichov
  • 11
  • 2
  • There just isn't much reason to suspect the library, especially given how often it has been hammered and how little it does. Much more likely is that this goes wrong in the device firmware. Do what works. – Hans Passant Sep 22 '17 at 18:54
  • Device firmware was my first guess, especially because it is also part of my project. Therefore, I implemented check of the stream buffer integrity before and after the transfer. No problems were found. – S.Chrichov Sep 23 '17 at 13:25
  • If not library nor firmware - so, only hardware remains? – S.Chrichov Sep 23 '17 at 13:31

1 Answers1

0

Answering my own question...

Hans' comment was correct, the problem was rooted in firmware.

Further details may be interesting for device firmware developers, especially if they use Atmel Cortex M7 series as I do.

In this series, USB controller includes dual-port RAM for endpoint buffering. The DPRAM is allocated and managed solely by hardware. Firmware initializes allocation by setting ALLOC bit in the endpoint control register. User manual requires the firmware should set ALLOC bits in ascending order. Once upon project history, I changed endpoint address in the endpoint descriptor not realizing that this change violates ascending order of DPRAM allocation. As a result, endpoint buffers appeared overlapped that caused data interference described in the question.

After fixing the bug, everything works fine.

S.Chrichov
  • 11
  • 2