STVP / STM8S-Discovery crashes Windows

[smh]

Posted on December 12, 2009 at 20:14

STVP / STM8S-Discovery crashes Windows

[smh]

Posted on May 17, 2011 at 15:05

I hope I'm doing something stupid, but if I try to get STVP to communicate with my STM8S-Discovery board it crashes Windows - the crash report says it's due to a driver fault.

I'm running XP Pro SP3 and STVP 3.1.3

I installed STVP then plugged the Discovery in. The STM8S-Discovery User Manual (UM0817) says: ''The driver for ST-Link is installed automatically when the USB is connected.''

Windows configures the device as a USB mass-storage device using a generic Microsoft driver, which is not what I expected. Though it does contain 3 Internet shortcuts to STM web pages, so someone evidently expected it to be accessed as a disk sometimes.

The STM8S-Discovery runs the Discover program OK (flashing green LED changes speed when you touch the pad), but there's no sign of activity on the ST-Link part of the board.

If I try to read anything from the device - in particular the option bytes as per section 4 of UM0834: ''Developing and debugging your STM8S-DISCOVERY application code'' - Windows crashes immediately.

Any suggestions?

[ This message was edited by: smh on 30-11-2009 01:12 ]

[smh]

Posted on May 17, 2011 at 15:05

Perhaps I can tempt someone to reply to some direct questions:

• Has anyone got an STM8s-Discovery running successfully with STVP?

• If so, what driver is associated with the device? (You can check the properties of the device in Windows Device Manager).

• How did you install that driver?
  I'm out of ideas at the moment and as things stand my promising little evaluation board is not even heavy enough to be a good paperweight!

[rexw]

Posted on May 17, 2011 at 15:05

Pretty quiet board. I just got the board and I managed to compile the example. As far as I see the only driver is the generic USB disk driver. I did not install anything. There may be something else but it isn't registered in Windows. This comes from someone who is far from an expert and would be more comfortable doing this on linux or mac. BTW this is running on WinXP via VMWare on a Mac.

When it uploaded and communicated with the board the LED flashed like nuts so I know it was working.

[smh]

Posted on May 17, 2011 at 15:05

A bit more info, in case anyone at ST is interested:

• Both STVP and STVD crash Windows on my machine when they try to connect to the device (Read from device, start debugging etc.)

• The crash happens whether or not the board is connected to the PC.

• Dissecting the crash dump files shows the crash happening in the NVidia RAID driver. (I guess this explains why my other PC is OK, since it doesn't have a RAID).

• I upgraded to the latest version of the NVidia drivers last night. The crash continues and is still in the RAID driver, but in a different place. (FWIW it looks like a memory reference through an uninitialised pointer).

• The PC is otherwise stable and reliable
  So it seems something that these tools are doing when they are searching for a device to connect to is enough to trip up NVidia.
  I could be trapped here, because NVidia is unlikely to be very worried about compatibility with comparatively unusual programming tools, and ST can probably claim that the bug is not in their code.
  However, I suspect I may not be the only person trying these tools who has an NVidia chipset on the motherboard, so it might be worth ST taking a look at the problem. If anyone wants to investigate I'd be happy to provide more information, or do other tests.

[smh]

Posted on May 17, 2011 at 15:05

Thanks for the feedback.

I just tried on a different computer and it communicates OK - flashing red LED as you say.

So now I have to figure out why my main machine crashes so horribly: both machines are XP Pro SP3 / AMD and as far as I can see both are using the same driver versions for USB Storage Device and Disk Drive.

[smh]

Posted on May 17, 2011 at 15:05

A bit more info:

When you start debugging in STVD it appears to spawn gdb7.exe, with the command line:

gdb7.exe --quiet --command=swim\gdbswim_stlink.ini

Issuing this command from a command shell starts up gdb OK

gdbswim_stlink.ini defines four user commands for gdb:

emulator-reset-port

emulator-reset-port-mcu

emulator-reset-hotplug-port

emulator-reset-keepswim-port-mcu

And the following command in gdb crashes Windows:

(gdb) emulator-reset-port 0

This is the definition of emulator-reset-port:

Code:

define emulator-reset-port

target gdi -dll swimstm_swim.dll -stlink3 -port $arg0

This pulls in stm_swim.dll, which in turn loads STLinkIIIUSBDriver.dll

I guess STLinkIIIUSBDriver.dll is searching through the attached disks to find an stlink device, and something in that search process is blowing up my RAID driver.

So, if I knew how this search is being done, I could write a small program to reproduce the problem and report the bug to NVidia...

[pdadev]

Posted on May 17, 2011 at 15:05

Hi there.

Great work with the troubleshooting that you've done so far! I'm relatively new to microcontrollers, but have worked in software quite a bit. The mods at this forum may not want us to go in-depth with hooking into their code, but if they are unwilling to support you as a customer, you should be able to troubleshoot and correct the issue yourself.

After taking a quick look at the DLL you mentioned, there are only 8 named exports, so writing a small shim to log the functions as they're called and the parameters they're called with shouldn't be too much trouble. If you're using windebug or another Ring0-based debugger you may be able to breakpoint the functions and avoid that.

The exported functions are indeed for enumerating and opening storage devices. The thing that I question is that this may not be an Nvidia problem, but instead the STLINK functions mistaking your RAID controller for something else and Opening/Sending an unsupported call or an allocation of the resource is failing (since it is the wrong type of device) and there is no error-checking to avoid a null-pointer in the driver.

I would suggest shimming the USBDriver.dll and logging the STMass_* exports to determine the last values and the function where the fault occurs. Patching in a work-around would be possible at that point, but it would be nice if the ST guys could facilitate this by throwing out a Debug version of the file for you to be able to avoid writing an intermediate DLL and then creating a properly patched build.

[smh]

Posted on May 17, 2011 at 15:05

I've used windbg to trace a bit more of what's going on. By setting a breakpoint when STLinkIIIUSBDriver.dll is loaded, I can see the exports and set breakpoints on them all, then trace into the code looking for tell-tale kernel calls.

The crash occurs when STLinkIIIUSBDriver!STMass_SendCommand calls kernel32!DeviceIoControl on the D: drive. It's already been through the same process on C: without problems. (C: and D: are both partitions on the RAID disk).

I'm now trying to work out which DeviceIoControl function is being called. dwIoControlCode = 0x000007a8. The parameters to the same call for the C: drive looked slightly suspect to me, see below, but the call succeeded. Unfortunately I didn't catch all the values on the call to D: this time round.

Parameters for DeviceIoControl call on C:

Code:

88 07 c3 00 handle (0x00c30788) <- refers to \.C:

a8 07 00 00 dwIoControlCode (0×000007a8) <- what function is this?

45 f9 12 00 lpInBuffer (0x0012f945) <- valid data memory

88 13 00 00 nInBufferSize (5000)

01 06 f1 80 lpOutBuffer (0x08f10601) <- Garbage ?

00 00 00 00 nOutBufferSize 0x0

00 00 00 00 lpBytesReturned (NULL)

00 00 00 00 lpOverlapped (NULL)

MSDN says this about lpOverlapped and lpBytesReturned:

''If lpOverlapped is NULL, lpBytesReturned cannot be NULL. Even when an operation returns no output data and lpOutBuffer is NULL, DeviceIoControl makes use of lpBytesReturned. After such an operation, the value of lpBytesReturned is meaningless''.

This is a painful process, especially because running the program too far crashes Windows and I have to set everything up again. Please, is there someone from ST listening prepared to make this task a bit easier by checking over the code (even telling me what the DeviceIoControl function is would be a help) or publishing the codeefragment that is searching for the ST-Link device?

[pdadev]

Posted on May 17, 2011 at 15:05

That is very odd.

Does the gdb reset-port command still pertain to what you said with: ''The crash happens whether or not the board is connected to the PC. ''?

If so, have a go at setting a breakpoint on the enum_getdevice function (bp 10017945) from windbg. Step over the call and see if eax is returning 0 when the board's not connected. There are notes within the DLL for what the various IOCTL ''errors'' could be (look for ''Cmd (status ='' in stm_swim.dll). There are no hard-coded calls with the parameter that you posted in the USB Driver DLL that I could outright see, but I would still be curious if the enumeration function is erroneously reporting that you have a device when none is present. Why ''SendCommand'' to an unsupported device? Also, if you could give the return eip from the stack on the fatal DeviceIOControl call, that could help as well.

I absolutely agree that ST should facilitate troubleshooting this, however.

[pdadev]

Posted on May 17, 2011 at 15:06

Wow.. finally. This should be at least a bit promising.

Breakpoint on ''GetDriveTypeA'' (exports from Kernel32).

Do a return from the jump (shift-11) which should throw you onto: lea ecx, [ebp-0Ch] \ lea edx .. etc etc. Step-Over down a bit and you'll see a function that takes 0s and 3s as params (push 0 \ push 3 \ push 0 \ push 3).

If cmp esi, FFFFFFFF does not trigger the je, the params are pushed and the DeviceIOControl function gets called.

This is in Sendcommand, called from the STMass_Enum_Reenumerate. The value of the parameters at EIP 60aa9e (this could be different since it's a DLL and might be relocated) should let you know EXACTLY what is being sent the moment your system dies.

If it can be established that this is the API call that is causing the failure, it might be possible to instantiate the enumeration past the point of failure as a quick-and-dirty patch to get it working on your system until the manufacturer actually supports their product.

---

I'm using the Windows 7 RTM at the moment, and the STVP works fine. there are references in the files to the Mass Storage Device driver.. it just seems that they've implemented their own IO control codes to set the device to different modes of receiving data.

If your board were up, you can also change the ini that GDB uses (where the emulator-reset-port command is defined) and add ''-SPY3 (filename)'' to get some fairly verbose logs. Unfortunately, the extent that would help with the BSOD problem is that it would tell you that the GetProcaddress/LoadLibrary for STMASS_* worked.