Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Connection to USB Freezing #30

Open
vaibhav-kapoor opened this Issue · 8 comments

3 participants

@vaibhav-kapoor

Hi, just wanted to mention really appreciate all the work you guys are doing.

I am running Fedora 16, and having incredible issues getting stm32f4discovery board working consistently.
I was able to get ./st-util working and was able to load the code, but very quickly the microcontroller stops responding. This is the output on the st-util:

[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)
[!] send_recv
libusb_submit_transfer(-6)

This occurs continuously, I can't stop the st-util process at all, no matter what I do. The continue command in gdb always hangs the st-util. It is an uninterruptable process. And the only way to fix it is to restart the computer. I couldn't find any way to the get it working without restarting the entire computer. GDB consistently hangs. I seem to get flash working relatively well, it doesn't hang to to much, but it happens after a while. I am having a bit of a tough time figuring everything out, but this is making things far more difficult.

If I disconnect the board and reconnect it the LED close to USB blinks RED. A lot of the issues I can't seem to find info on anywhere, it doesn't looks like its a typical problem. Any help is really appreciated.

Also I noticed the makefiles for all the libraries on the recent update. I really appreciate this as well, for the last couple days I was working on getting the makefiles for the libraries, I had just finished gotten it working, but I can just use yours now.

Again thanks for the help.
TheLegace

@jnosky

CTRL-C might break out of the server.
Try reading and writing to flash with flash.exe.
Have you run the test_usb.exe ? Any problems?
Does the stlink build all build without any error messages?

@vaibhav-kapoor

Everything works at least once, before it get's stuck. Like I said I have explored every way to kill the process, CTRL+C doesn't work, I have tried sending back every possible kill signal, but the process refuses to die.

I will give test_usb a shot, but it's not like nothing works, it just stops working after a while. Flash is working for some time, and stlink builds perfectly.

@vaibhav-kapoor

This is my test_usb output:

-- version
mode before doing anything: 2
-- enter_swd_mode
-- mode after entering swd mode: 2
-- chip id: 0x413
-- core_id: 0x2ba01477
cpuid:impl_id = 0x41, variant = 0
cpuid:part = 0xc24, rev = 0x1
-- read_sram
FP_CTRL
-- status
-- reset
-- status
-- step
-- run
-- exit_debug_mode

@vaibhav-kapoor

One more thing is there anyway I can either restart the entire USB service/driver or something that way it's as if I rebooted the computer but only for the USB. Honestly I love Linux for the fact that I don't have to restart, so I am really hating having to restart.

I just tried writing the discovery project in your update, it writes, but since the file is relatively big it fails, here is output using write:

2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***
libusb_submit_transfer(-6)
[!] send_recv
2011-11-16T12:26:20 DEBUG src/stlink-common.c: *** stlink_read_mem32 ***

test_usb outputs nothing when the thing is frozen, it just hangs.

@vaibhav-kapoor

I don't know if this helps, but once the libusb freezes, and I disconnect the device and do lsusb, the Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics doesn't disappear, which is totally weird.

Here is some more info if you would like:

Bus 003 Device 003: ID 0483:3748 SGS Thomson Microelectronics
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)

bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x0483 SGS Thomson Microelectronics
idProduct 0x3748
bcdDevice 1.00
iManufacturer 1 STMicroelectronics
iProduct 2 STM32 STLink
iSerial 3 Q�kH�IS'�
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 4 ST Link
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 0
Device Status: 0x0000
(Bus Powered)

I think both flash, and st-util end up becoming a zombie process. I will test with other distro, but I'm sure it's a kernel issue, but no one else seems to be having trouble. I am assuming your not.

Thanks for everything.

@vaibhav-kapoor

After going through distro after distro, I manged to figure out that this looks like a either a Fedora 16 problem, or a newer kernel issue.
I was able to successfully use your program without any hiccups or problems in Ubuntu 11.04. I don't remember the specifics, but if you want me to do any testing feel free to ask.
Thanks.

@karlp

I bet this is the same as #31

Looks like the USB isn't getting cleaned up properly in certain exit cases, and restarting the app doesn't clean it up either. Having a bit of a look at a proper fix

@vaibhav-kapoor

When I get some time after my exams I will try and help out with the project and fix the bug (not a fan of ubuntu). Are you running latest kernel? We could also try and compare libusb versions.

On the working Ubuntu I have is 1.0.8-2.

Oh also, if you ever get a chance and update the write program could add a command that resets the microcontroller. I don't know if it's normal, but after writing I have to power cycle the stm32f4 board and my program starts running.

Thanks appreciate it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.