2019-10-03 07:00 AM
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
2019-10-03 12:19 PM
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
2019-10-04 02:12 AM
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;
2019-10-04 04:07 PM
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
2019-10-06 01:15 AM
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
2019-10-06 04:56 AM
2019-10-06 09:09 AM
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)
2019-10-06 10:27 AM
2019-10-07 01:42 AM
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
2019-10-07 05:05 AM