cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 Virtual COM Port Driver crashes randomly

knut2
Associate II

I use the current version 1.5.0 of the STM32 Virtual COM Port Driver.

Sometimes i got a bluescreen during my running Win32 App.

As far I know, this problem is related to usbser.sys. But how to fix it?

I'm using Win7 x64 and the usbser.sys is version 6.1.7601.18247.

I do not expect any help from microsoft.

But can STM force a bugfix or: Develop an own CDC driver for Windows?

Knut

13 REPLIES 13
Pavel A.
Evangelist III

The "bluescreens" usually come with some code or message. Can you recall and post this message, please?

Can you recall when usually these bluescreens occur? (for example - when somebody touches the board or bends the cable...)

> But can STM force a bugfix or: Develop an own CDC driver for Windows?

The "Virtual COM port driver" is the ST's own CDC driver.

-- pa

-- pa

knut2
Associate II

Hi Pavel,

here is my (Delphi-)code. It is a thread, which waits for data from USB-VCP and, depending from the protocol, it tries to read more or less (aBufLen) data bytes.

Reading data is done by asynchronous file i/o (using overlapped struct) to let the thread sleep (WaitForSingleObject), when no data is received from device.

When enough bytes are received, the data protocol (CRC or else) will be checked and payload extracted.

The data istself is a properity protocol. I expect no issues with that. Just some bytes in an specific order.

The bluescreen comes without any user action. Just a (overnight) running process and sometimes in the morning bluescreen is presented.

But I also had the bluescreen, when running my program in debugger and just waiting for specific sensor data.

The program is a recording app, which receives and stores data, which comes from several sensors (STM32 board, O2 / CO2 sensors).

It maybe some packes per second but also some hundred packets per second. Each packet about 10 ... 150 Bytes.

Current bluescreens happens with only few packets per second.

As far i know, only the *.inf file is STM specific. The usbser.sys is Mircosoft.

Knut

function TCommO.CommReadA(var aBuf; aBufLen: Cardinal; aTimeOutMS: DWORD): Cardinal;
var
  BytesInBuf: Cardinal;
begin
  result := 0;
  if Not CommIsOpen() then exit;
 
  BytesInBuf := CommBytesInRxQueue(); // Windows Buffer
  if (BytesInBuf = 0) then
    aBufLen := 1 // if buffer empty, wait for the first char (continue reader thread does not make sense), but receive complete in next call
  else
    if BytesInBuf < aBufLen then aBufLen := BytesInBuf; // try to receive all, but consider buffer size
 
  if Not ReadFile(m_CID, aBuf, aBufLen, result, @m_Ovl_Read) then
  begin
    if GetLastError() = ERROR_IO_PENDING then
    begin
      WaitForSingleObject(m_Ovl_Read.hEvent, aTimeOutMS);
      GetOverlappedResult(m_CID, m_Ovl_Read, result, FALSE);
 
      if result = 0 then
      begin
        if GetLastError() = ERROR_IO_INCOMPLETE then
          CancelIo(m_CID);
      end;
    end
    else
    begin
      CommError();
    end;
  end;
end;
 
function TCommO.CommBytesInRxQueue(): DWORD;
var
  err: Cardinal;
  MaxLoop: Cardinal;
  stat: COMSTAT;
begin
  result := 0;
  If CommIsOpen() Then
  begin
    MaxLoop := 100;
    repeat
      ClearCommError(m_CID, err, @stat);
      Dec(MaxLoop);
    until (err = 0) OR (MaxLoop = 0);
    if MaxLoop > 0 then
      result := stat.cbInQue
    else
      Result := 0;
  End;
End;

Pavel A.
Evangelist III

Hello Knut,

The code looks benign enough. It is a pity that you cannot recall more bugcheck info. A memory dump would be helpful too.

> As far i know, only the *.inf file is STM specific. The usbser.sys is Mircosoft

Yes, you're right. But we don't know what exactly causes the crashes, so we cannot blame the usbser.sys alone.

It isn't likely that ST will provide a special driver for Windows version that soon will go out of its support period.

-- pa

knut2
Associate II

Hi Pavel,

thanks for analyzing my code and take the time to look at my issue.

I have enabled the (big) memory dump in windows to provide you with a memory dump after next bluescreen.

No idea, if a small memory dump also would be enough. If so, please let me know, it would reduce the file i have to upload here.

By the way:

I hope it is possible to upload such huge files here and that is no security risk, when (public) uploading memory dumps...

And: How do you analyze such dumps? I always interested in that, but never done it... :)

Do you think, if there are other things i can do (logging on STM-controller side) to find out the problem?

Knut

knut2
Associate II

He is my first file (big flie was not created, no idea, why)...

Pavel A.
Evangelist III

Hi Knut,

This dump (well, minidump) is perfect.

Indeed the usbser driver is a possible culprit. But this machine has a Renesas USB3 controller with Renesas driver.

Win7 does not have native support for USB3 yet, the vendor's drivers haven't been tested well enough

for compatibility with various devices.

Virtualbox USB redirector also can contribute to the problem,.

So the best I can advice is to connect to a USB2 port if the machine has a USB2 controller.

Else, connect it thru a good USB 2.0 hub, high or full speed.

If your device behaves well with Win 10 or Linux hosts, there's probably nothing to do on the STM32 side.

Regards,

Pavel A.

(in a previous life, Windows kernel was my day job. it was 200 yeas ago or so)

Pavel A.
Evangelist III
 
knut2
Associate II

Hi Pavel,

thanks for analyzing the file.

Yes, there is an ExSys (EX-11494-2) PCIe to 4x USB3 Adapter card in the PC. It has an Renasas µPD720201 Chip.

Unfortunately i could not find a newer driver than 3.0.23 (08 / 2012).

In the past (other project) I ran into problems, when connecting 4x FTDI FT4232HL to a single OnBoard-USB2-Port (randomly dis-/reappearing COM Ports in device manager).

Inspecting with USBView shows additional internal USB (Root?) Hubs which shares bandwith with possible other connected devices to other OnBoard USB Ports.

So, I decided to use this AddOn Card in hope to have more reserve in Bandwith.

I assume using this PCIe AddOn Card is the shortest (direct) way, of connecting USB3 Ports to the Chipset/CPU.

At Maximum i have connected to each of this 4x USB3 Ports a Hub with extends to 16x USB3 Ports (ExSys EX-1116HMVS).

Each of this 16 Ports is connected to one STM Device which can send up to 300 Packets per second (see my second post).

Note: Bluescreen came up with only a single STM32...

I will do a test with a OnBoard-USB2-Port and let you know the result with that...

Knut

knut2
Associate II

So, i'm back with a new dump file.

Also with an OnBoard USB2 Port it crashes.